Figure out what to do about weak tables + shrinkable tables in memory limiting

[HaroldCindy]

Walking the user's heap as a graph works great when we don't care about when the GC actually cleans up something that a user dropped a reference to, but having a GC that works on every script's heap falls a bit short when dealing with weak tables.

Obviously, weak table contents are managed by the GC and only cleaned out once the GC is able to realize what's reachable and what's not. Weak references that are live still cost memory, and we include them in our cost model for calculating user heap size.

I think we may need a separate utility for cleaning up a script's weak tables if the VM thinks the script is at risk of OoMing. We can use a similar heap walker as in lgctraverse.cpp, just keeping track of weak table contents as well as whether we see any strong references to their contents anywhere in the script. I'll need to think about the safety of doing this, as beforeallocate() hooks can trigger at any point where dynamic allocation is about to occur, but weak tables are normally only cleaned at GC safepoints. We might end up with cases where a script is operating on a table and the table contents change out from under it due to our cleanups.

I suspect we might be able to get away with not ever doing emergency clean-up on LuaTables that exist somewhere on the current function's stack, maybe also in upvalues.

Shrinkable tables I'm not entirely sure what to do about yet. Maybe the same thing?

[HaroldCindy]

Beginning to think we may have to make an emergency "mini-GC" that runs during explicitly heap size calculation that can walk a user script state and clean weak references if no strong references are found. We're going to be manually walking all the user thread's user-allocated nodes, so maybe a two bird one stone situation.