Previously any T_OBJECT with >= 94 IVARs would crash during compaction
attempting to make an object too large to embed.

These tests failed with RHEL10

https://rubyci.s3.amazonaws.com/rhel10/ruby-master/log/20250828T093003Z.fail.html.gz

We should skip reference updating for entries in too complex generic ivars
that are special constants. This fixes the following crash:

    MAX_SHAPES = 0x80000

    MAX_SHAPES.times do |i|
      o = []
      o.instance_variable_set(:"@foo#{i}", 1)
    end

    o = []

    o.instance_variable_set(:"@a", 123)

    GC.compact

It's testing whether GC compaction is supported in general.

Now that we've inlined the eden_heap into the size_pool, we should
rename the size_pool to heap. So that Ruby contains multiple heaps, with
different sized objects.

The term heap as a collection of memory pages is more in memory
management nomenclature, whereas size_pool was a name chosen out of
necessity during the development of the Variable Width Allocation
features of Ruby.

The concept of size pools was introduced in order to facilitate
different sized objects (other than the default 40 bytes). They wrapped
the eden heap and the tomb heap, and some related state, and provided a
reasonably simple way of duplicating all related concerns, to provide
multiple pools that all shared the same structure but held different
objects.

Since then various changes have happend in Ruby's memory layout:

* The concept of tomb heaps has been replaced by a global free pages list,
  with each page having it's slot size reconfigured at the point when it
  is resurrected
* the eden heap has been inlined into the size pool itself, so that now
  the size pool directly controls the free_pages list, the sweeping
  page, the compaction cursor and the other state that was previously
  being managed by the eden heap.

Now that there is no need for a heap wrapper, we should refer to the
collection of pages containing Ruby objects as a heap again rather than
a size pool

Using a SEGV signal for timeout makes it difficult to tell if it's a real
SEGV or if it timed out, so we should just use the default signals.

It is too flaky on macOS GitHub Actions

As preparation for https://bugs.ruby-lang.org/issues/20205
making sure the test suite is compatible with frozen string
literals is making things easier.