fix memory leaks due to retained tagify, sortable or tooltipster instances

[Codas]

This PR fixes memory leaks in character/npc/hazard/party/kingdom/item sheets and various other places.

Any application currently using Sortable, tooltipster or Tagify is currently leaking memory (some references + the entire detached application dom tree) because these utilities register global event handlers or other global references that survive the application elements being detached from the DOM.

The solution to this to use the respective destroy methods these libraries provide. Either .destroy() on the Sortable or Tagify instances or $(element).tooltipster('destroy') for tooltipster.
This is done by keeping references to the active instances and destroying and nulling them when the application is closed, new event handlers are registered or rule element forms are not used anymore.

The memory profiles in the coming examples were done the following way:

• Reload foundry
• perform activity once to trigger any lazy allocations that are done only once for each application
• trigger manual garbage collection in chrome memory profiler
• start memory profiling
• do the activity three more times, each time running manual garbage collection after the activity is performed
• stop memory profiling

Ideal results are: Three spikes in the allocation that reset to a flat line of exactly the same height as before the spike.

These are the results:

NPC Sheet

before PR

after PR

Character Sheet

before PR

after PR

Hazard Sheet

_Note: Hazard has to be in "unlocked" mode for tagify to be instantianted and triggere the memory leak_

before PR

after PR

Kingdom Sheet

_Note: I was unable to test this one as I don't have access to the Kingmaker Premium Module._

before PR
N/A
after PR
N/A

Party Sheet

before PR

after PR

IWR Editor

before PR

after PR

Compendium Browser

_Note: This requires the compendiom browser to be opened with a tab that has tagify instances. The Equipment tab for example._

before PR

after PR

Pick a Thing Prompt

_Note: TODO describe which thing was picked_

before PR

after PR

Encounter Tracker

_Note: This occured whenever the listeners were activated again. For testing, the encounter turn was advanced by one step._

before PR

after PR

Note for Rule Elements: This was tested by creating the rule element for a standalone item, then deleting the rule element again without closing the item sheet. Even closing the item sheet however, memory was not freed.

Rule Element Forms: Actor Traits

_Note: TODO - how to test?_

before PR

after PR

Rule Element Forms: Aura

before PR

after PR

Rule Element Forms: Fast Healing

_Note: Type has to be set to "regeneration" for memory leak to trigger_

before PR

after PR

Rule Element Forms: Roll Note

before PR

after PR

Campaign Feature

before PR

after PR

Deity Sheet

before PR

after PR

Feat Sheet

before PR

after PR

Spell Sheet

before PR

*after PR

Scene Config Sheet

before PR

after PR

Homebrew Language Settings sheet

before PR

after PR

Skill Check Prompt Macro

before PR

after PR

[CarlosFdez]

What should we be looking at in the profiler? I will be honest and admit that for larger performance concerns outside of time spent, these finer features of the debugger are lost on me, and it seems like the heap is actually larger now overall. I'd be fine with the easiest to understand guide you are aware of.

Are you aware of the code/known issue/etc for all 3 of these libraries and can you link them? One of them being a leak wouldn't be a surprise, but all 3 is a bit wild. What's the likelihood that these global listeners aren't simply reused for all 3 once registered? Or that its memory that hasn't been gc'd yet? seems you accounted for this with manual gc in the profiler.