Fix frozen status loss when moving objects

	[Bug #19536]

	When objects are moved between size pools, their frozen status is lost
	in the shape. This will cause the frozen check to be bypassed when there
	is an inline cache. For example, the following script should raise a
	FrozenError, but doesn't on Ruby 3.2 and master.

	    class A
	      def add_ivars
	        @a = @b = @c = @d = 1
	      end

	      def set_a
	        @a = 10
	      end
	    end

	    a = A.new
	    a.add_ivars
	    a.freeze

	    b = A.new
	    b.add_ivars
	    b.set_a # Set the inline cache in set_a

	    GC.verify_compaction_references(expand_heap: true, toward: :empty)

	    a.set_a
	---
	 shape.c                      |  2 +-
	 test/ruby/test_gc_compact.rb | 28 ++++++++++++++++++++++++++++
	 2 files changed, 29 insertions(+), 1 deletion(-)

	Fix undefined behavior in shape.c

	Under strict aliasing, writing to the memory location of a different
	type is not allowed and will result in undefined behavior. This was
	happening in shape.c due to `rb_id_table_lookup` writing to the memory
	location of `VALUE *` that was casted from a `rb_shape_t **`.

	This was causing test failures when compiled with LTO.

	Fixes [Bug #19248]

	Co-Authored-By: Alan Wu <alanwu@ruby-lang.org>
	---
	 shape.c | 13 +++++++++++--
	 1 file changed, 11 insertions(+), 2 deletions(-)

RubyVM::Shape is usually not available (you need SHAPE_DEBUG macro,
which is not defined by default). So it seems confusing to leave
RubyVM::Shape in the document.

This hides only method definitions because, well, I can't find a way to
hide things defined by rb_define_const or rb_struct_define_under. I gave
up making the C-based documentation right. You should define things in
Ruby instead.

Make printing shapes better, use a struct instead of specific methods
for each field on a shape.

Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>

When moving Objects between size pools we have to assign a new shape.

This happened during updating references - we tried to create a new shape
tree that mirrored the existing tree, but based on the root shape of the
new size pool.

This causes allocations to happen if the new tree doesn't already exist,
potentially triggering a GC, during GC.

This commit changes object movement to look for a pre-existing new tree
during object movement, and if that tree does not exist, we don't move
the object to the new pool.

This allows us to remove the shape allocation from update references.

Co-Authored-By: Peter Zhu <peter@peterzhu.ca>

When an object becomes "too complex" (in other words it has too many
variations in the shape tree), we transition it to use a "too complex"
shape and use a hash for storing instance variables.

Without this patch, there were rare cases where shape tree growth could
"explode" and cause performance degradation on what would otherwise have
been cached fast paths.

This patch puts a limit on shape tree growth, and gracefully degrades in
the rare case where there could be a factorial growth in the shape tree.

For example:

```ruby
class NG; end

HUGE_NUMBER.times do
  NG.new.instance_variable_set(:"@unique_ivar_#{_1}", 1)
end
```

We consider objects to be "too complex" when the object's class has more
than SHAPE_MAX_VARIATIONS (currently 8) leaf nodes in the shape tree and
the object introduces a new variation (a new leaf node) associated with
that class.

For example, new variations on instances of the following class would be
considered "too complex" because those instances create more than 8
leaves in the shape tree:

```ruby
class Foo; end
9.times { Foo.new.instance_variable_set(":@uniq_#{_1}", 1) }
```

However, the following class is *not* too complex because it only has
one leaf in the shape tree:

```ruby
class Foo
  def initialize
    @a = @b = @c = @d = @e = @f = @g = @h = @i = nil
  end
end
9.times { Foo.new }
``

This case is rare, so we don't expect this change to impact performance
of most applications, but it needs to be handled.

Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>

Count how many "variations" each class creates. A "variation" is a a
unique ordering of instance variables on a particular class. This can
also be thought of as a branch in the shape tree.

For example, the following Foo class will have 2 variations:

```ruby
class Foo ; end

Foo.new.instance_variable_set(:@a, 1) # case 1: creates one variation
Foo.new.instance_variable_set(:@b, 1) # case 2: creates another variation

foo = Foo.new
foo.instance_variable_set(:@a, 1) # does not create a new variation
foo.instance_variable_set(:@b, 1) # does not create a new variation (a continuation of the variation in case 1)
```

We will use this number to limit the amount of shapes that a class can
create and fallback to using a hash iv lookup.

Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>

This reverts commit 9c54466e299aa91af225bc2d92a3d7755730948f.

We're seeing crashes in Shopify CI after this commit.

When moving Objects between size pools we have to assign a new shape.

This happened during updating references - we tried to create a new shape
tree that mirrored the existing tree, but based on the root shape of the
new size pool.

This causes allocations to happen if the new tree doesn't already exist,
potentially triggering a GC, during GC.

This commit changes object movement to look for a pre-existing new tree
during object movement, and if that tree does not exist, we don't move
the object to the new pool.

This allows us to remove the shape allocation from update references.

Co-Authored-By: Peter Zhu <peter@peterzhu.ca>

If the rb_id_table_lookup fails, then res is not updated so it cannot be
any value other than null.