[Bug #20719] `Float` argument must be ASCII compatible

	rb_obj_setup: do not copy RUBY_FL_SEEN_OBJ_ID

	[Bug #20250]

	We're seting up a new instance, so it never had an associated
	object_id.

	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

	[Bug #19833] Fix index underflow at superclasses of `BasicObject`

	---
	 object.c                | 4 ++++
	 test/ruby/test_class.rb | 7 +++++++
	 2 files changed, 11 insertions(+)

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

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>

In order to preserve the values when TrueClass, FalseClass or NilClass
are stored in ivars

The removed code is a duplicate of the code above.

obj_ivar_set and vm_setivar_slowpath is essentially doing the same thing,
but the code is duplicated and not quite implemented in the same way,
which could cause bugs. This commit refactors vm_setivar_slowpath to use
obj_ivar_set.

New T_OBJECT objects will have a T_OBJECT shape