Don't pin named structs defined in Ruby

	[Bug #20311]

	`rb_define_class_under` assumes it's called from C and that the
	reference might be held in a C global variable, so it adds the
	class to the VM root.

	In the case of `Struct.new('Name')` it's wasteful and make
	the struct immortal.

	Make Struct memory leak test faster

	[Bug #20311]

	It times out on some platform, so we can reduce iterations.
	On my machine it completes in 250ms and RSS grows 8X.

Add memory leak test for eval kwargs

	De-dup identical callinfo objects

	Previously every call to vm_ci_new (when the CI was not packable) would
	result in a different callinfo being returned this meant that every
	kwarg callsite had its own CI.

	When calling, different CIs result in different CCs. These CIs and CCs
	both end up persisted on the T_CLASS inside cc_tbl. So in an eval loop
	this resulted in a memory leak of both types of object. This also likely
	resulted in extra memory used, and extra time searching, in non-eval
	cases.

	For simplicity in this commit I always allocate a CI object inside
	rb_vm_ci_lookup, but ideally we would lazily allocate it only when
	needed. I hope to do that as a follow up in the future.

We should set the m_tbl right after allocation before anything that can
trigger GC to avoid clone_p from becoming old and needing to fire write
barriers.

Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>

Too complex classes use a hash table to store ivs, and should always pin
their IVs.  We shouldn't touch those classes in compaction.

... because GCC 13 warns it.

```
In file included from class.c:24:
In function ‘RCLASS_SET_ALLOCATOR’,
    inlined from ‘class_alloc’ at class.c:251:5,
    inlined from ‘rb_module_s_alloc’ at class.c:1045:17:
internal/class.h:159:43: warning: array subscript 0 is outside array bounds of ‘rb_classext_t[0]’ {aka ‘struct rb_classext_struct[]’} [-Warray-bounds=]
  159 |     RCLASS_EXT(klass)->as.class.allocator = allocator;
      |                                           ^
```
https://rubyci.s3.amazonaws.com/arch/ruby-master/log/20231015T030003Z.log.html.gz

Revert commit "Directly allocate FrozenCore as an ICLASS",
813a5f4fc46a24ca1695d23c159250b9e1080ac7.

SunC warns use of `NULL`, pointer to data as function pointers.

It's a bad idea to overwrite the flags as the garbage collector may have
set other flags.

This reverts commit 10621f7cb9a0c70e568f89cce47a02e878af6778.

This was reverted because the gc integrity build started failing. We
have figured out a fix so I'm reopening the PR.

Original commit message:

Fix cvar caching when class is cloned

The class variable cache that was added in
ruby#4544 changed the behavior of class
variables on cloned classes. As reported when a class is cloned AND a
class variable was set, and the class variable was read from the
original class, reading a class variable from the cloned class would
return the value from the original class.

This was happening because the IC (inline cache) is stored on the ISEQ
which is shared between the original and cloned class, therefore they
share the cache too.

To fix this we are now storing the `cref` in the cache so that we can
check if it's equal to the current `cref`. If it's different we don't
want to read from the cache. If it's the same we do. Cloned classes
don't share the same cref with their original class.

This will need to be backported to 3.1 in addition to 3.2 since the bug
exists in both versions.

We also added a marking function which was missing.

Fixes [Bug #19379]

Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>

This reverts commit 77d1b082470790c17c24a2f406b4fec5d522636b.