Add GC finalization hook

[dcodeIO]

Related: #383

This is a quick experiment for a finalization hook when managed objects become collected. A lot can go wrong here, especially when finalization messes with MM/GC state before freeing, so this is as low-level and unsafe as it gets. Doesn't bother with registering destructors (needs compiler support or a virtual destructor table, and suffers from the same challenges) but might be a starting point for anyone interested in playing with finalization in general / inform future design. Wondering if a mechanism along the lines of JS weakref can be implemented on top.

[dcodeIO]

Keeping this PR open as part of 2020 vacuum as it hasn't yet received enough feedback to make a proper decision just yet. Also considering, in case it appears useful, to merge just the __finalize runtime hook as a low-level building block to encourage experimentation. It's opt-in anyway and doesn't affect code not using it.

[dcodeIO]

Thinking about it a little more, since it doesn't affect existing code and is opt-in, let's just merge this. Shouldn't be a burden due to its simplicity, and enables everyone to experiment with finalization to aid future design of a proper API. Updated the test to check just __finalize without any design assumptions.

[jtenner]

How do we use this officially? Is there anything in the docs about it?

[dcodeIO]

An example of how to use it is the test file. Essentially, one has to add

@global function __finalize(ptr: usize): void {
  ...
}

as an additional runtime hook, which is then called with the pointer to the object being free'd right before it is. Not the final API of course (that'd be something more along the lines of FinalizationRegistry), just the integration point. Not sure if it deserves to be included in the docs just yet, but perhaps we can mention it within RT internals.

[jtenner]

This is amazing. Thank you.