Evaluate adding a stable heap to the memory manager

[jasone]

The current local heap design comprises a copying minor heap and a compacting major heap. There are
a few ways in which the current design mismatches needs:

• The minor heap is incapable of individual allocations larger than 2 MiB, and there is strong design-motivated pressure to limit the maximum allocation size to something on the order of 4 KiB, lest minor collections have a memory footprint larger than the on-die data cache. The current solution to large allocations is to place them in the major/global heaps, which means that large ephemeral allocations can trigger major collection overheads which overwhelm actual application computation.
• Asynchronous I/O (via io_uring) requires stable buffer locations. Such buffers can be serviced via a relatively simple span allocator (see Actor I/O heap #147), but at the expense of copyin/copyout for every buffer.
• Foreign function interface (FFI) APIs can be extremely challenging to use if the runtime doesn't provide any stable allocation mechanism. Without a stable heap, some FFI integrations have to fall back to using externally allocated (e.g. via mmap(2) or malloc(3)) memory and managing lifetimes via finalizers.

Were we to add a local stable heap to Hemlock's memory manager, it would probably have the following attributes:

• Support for a broad range of size classes, as small as 16 bytes. Some io_uring requests require allocating just a pair of u64 values.
• Distinction of typed versus raw (untyped) memory. Raw memory must be manually deallocated, since it exists independently of the reference graph.
• Optionally pinned allocation. Asynchronous I/O requires pinned allocations, but large allocations can be moved to the major/global heaps should they survive long enough to justify migration.
• GC frequency in the range between that of the minor and major heaps.
• Cohort aging to delay promotion to the major/global heaps.
• Card marking to support fast minor heap GC, i.e. without also GCing the stable heap.