Fix memory leak when duplicating too complex object

	[Bug #20162]

	Creating a ST table then calling st_replace leaks memory because the
	st_replace overwrites the ST table without freeing any of the existing
	memory. This commit changes it to use st_copy instead.

	For example:

	    RubyVM::Shape.exhaust_shapes

	    o = Object.new
	    o.instance_variable_set(:@a, 0)

	    10.times do
	      100_000.times { o.dup }

	      puts `ps -o rss= -p #{$$}`
	    end

	Before:

	    23264
	    33600
	    42672
	    52160
	    61600
	    71728
	    81056
	    90528
	    100560
	    109840

	After:

	    14752
	    14816
	    15584
	    15584
	    15664
	    15664
	    15664
	    15664
	    15664
	    15664

	Use an st table for "too complex" objects

	st tables will maintain insertion order so we can marshal dump / load
	objects with instance variables in the same order they were set on that
	particular instance

	[ruby-core:112926] [Bug #19535]

	Co-Authored-By: Jemma Issroff <jemmaissroff@gmail.com>
	---
	 gc.c                     | 10 ++++------
	 include/ruby/st.h        |  2 ++
	 object.c                 |  2 +-
	 ractor.c                 | 43 ++++++++++++++++++++++---------------------
	 shape.h                  |  6 +++---
	 st.c                     |  6 ++++++
	 test/ruby/test_shapes.rb | 21 +++++++++++++++++++++
	 variable.c               | 28 ++++++++++++++--------------
	 vm_insnhelper.c          |  2 +-
	 9 files changed, 74 insertions(+), 46 deletions(-)

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 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>

Cases like this:

```ruby
obj = Object.new
loop do
  obj.instance_variable_set(:@foo, 1)
  obj.remove_instance_variable(:@foo)
end
```

can cause us to use many more shapes than we want (and even run out).
This commit changes the code such that when an instance variable is
removed, we'll walk up the shape tree, find the shape, then rebuild any
child nodes that happened to be below the "targetted for removal" IV.

This also requires moving any instance variables so that indexes derived
from the shape tree will work correctly.

Co-Authored-By: Jemma Issroff <jemmaissroff@gmail.com>
Co-authored-by: John Hawthorn <jhawthorn@github.com>

We would like to differentiate types of objects via their shape.  This
commit adds a special T_OBJECT shape when we allocate an instance of
T_OBJECT.  This allows us to avoid testing whether an object is an
instance of a T_OBJECT or not, we can just check the shape.

This commit adds a `capacity` field to shapes, and adds shape
transitions whenever an object's capacity changes. Objects which are
allocated out of a bigger size pool will also make a transition from the
root shape to the shape with the correct capacity for their size pool
when they are allocated.

This commit will allow us to remove numiv from objects completely, and
will also mean we can guarantee that if two objects share shapes, their
IVs are in the same positions (an embedded and extended object cannot
share shapes). This will enable us to implement ivar sets in YJIT using
object shapes.

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

`iv_count` is a misleading name because when IVs are unset, the new
shape doesn't decrement this value. `next_iv_count` is an accurate, and
more descriptive name.

We only cache the destination shape id, but that can lead to false cache
hits.  This patch tests that we correctly handle false cache hits