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

	proc.c: get rid of `CLONESETUP`
	MIME-Version: 1.0
	Content-Type: text/plain; charset=UTF-8
	Content-Transfer-Encoding: 8bit

	[Bug #20253]

	All the way down to Ruby 1.9, `Proc`, `Method`, `UnboundMethod`
	and `Binding` always had their own specific clone and dup routine.

	This caused various discrepancies with how other objects behave
	on `dup` and `clone. [Bug #20250], [Bug #20253].

	This commit get rid of `CLONESETUP` and use the the same codepath
	as all other types, so ensure consistency.

	NB: It's still not accepting the `freeze` keyword argument on `clone`.

	Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>

merge revision(s) 82b57d7bfeefd717c10f7a5a3484aca6b3e708a3: [Backport #20162]

	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
	---
	 object.c                 |  3 +--
	 test/ruby/test_shapes.rb | 13 +++++++++++++
	 2 files changed, 14 insertions(+), 2 deletions(-)

RUBY_FL_PROMOTED is used by the garbage collector to track when an
object becomes promoted to the old generation. rb_obj_setup must not
copy that flag over because then it may become out-of-sync with the age
of the object.

This fixes a bug in Method#clone where the cloned Method object may get
RUBY_FL_PROMOTED incorrectly set.

Objects with the same shape must always have the same "embeddedness"
(either embedded or heap allocated) because YJIT assumes so. However,
using remove_instance_variable, it's possible that some objects are
embedded and some are heap allocated because it does not re-embed heap
allocated objects.

This commit changes remove_instance_variable to re-embed Object
instance variables when it becomes small enough.

For this public API, the callback is declared to take
`(ID, VALUE, st_data_t)`, but it so happens that using
`(st_data_t, st_data_t, st_data_t)` also
type checks, because the underlying type is identical.
Use it as declared and get rid of some casts.

That function is a bit too low level to called from multiple
places. It's always used in tandem with `rb_shape_set_too_complex`
and both have to know how the object is laid out to update the
`iv_ptr`.

So instead we can provide two higher level function:

  - `rb_obj_copy_ivs_to_hash_table` to prepare a `st_table` from an
    arbitrary oject.
  - `rb_obj_convert_to_too_complex` to assign the new `st_table`
    to the old object, and safely free the old `iv_ptr`.

Unfortunately both can't be combined into one, because `rb_obj_copy_ivar`
need `rb_obj_copy_ivs_to_hash_table` to copy from one object
to another.

It's only used to allocate the table with the right size,
but in some case we were passing `rb_shape_get_shape_by_id(SHAPE_OBJ_TOO_COMPLEX)`
which `next_iv_index` is a bit undefined.

So overall we're better to just allocate a table the size of the existing
object, it should be close enough in the vast majority of cases,
and that's already a de-optimizaton path anyway.

There is a handful of call sites where we may transition to
OBJ_TOO_COMPLEX_SHAPE if we just ran out of shapes, but that
weren't handling it properly.

If it runs out of shapes, or new variations aren't allowed, it will
return "too complex"