Defer freeing of mega block groups

Solves the quadratic worst case performance of freeing megablocks that
was described in issue #19897.

During GC runs, we now keep a secondary free list for megablocks that is
neither sorted, nor coalesced. That way, free becomes an O(1) operation
at the expense of not being able to reuse memory for larger allocations.
At the end of a GC run, the secondary free list is sorted and then
merged into the actual free list in a single pass.

That way, our worst case performance is O(n log(n)) rather than O(n^2).

We postulate that temporarily losing coalescense during a single GC run
won't have any adverse effects in practice because:

- We would need to release enough memory during the GC, and then after
  that (but within the same GC run) allocate a megablock group of more
  than one megablock. This seems unlikely, as large objects are not
  copied during GC, and so we shouldn't need such large allocations
  during a GC run.
- Allocations of megablock groups of more than one megablock are rare.
  They only happen when a single heap object is large enough to require
  that amount of space. Any allocation areas that are supposed to hold
  more than one heap object cannot use megablock groups, because only
  the first megablock of a megablock group has valid `bdescr`s. Thus,
  heap object can only start in the first megablock of a group, not in
  later ones.