Because checking the current box is not a cheap process.

Without this change, classes (including iclass) are allocated
as un-boxable classes after initializing user boxes (after starting
script evaluation). Under this situation, iclasses are created as
un-boxabled class when core modules are included by a class in the
root box, then it causes problems because it's in the root box but
it can't have multiple classexts.

This change makes it possible to allocate boxable classes even after
initializing user boxes. Classes create in the root box will be
boxable, and those can have 2 or more classexts.

Since singleton classes are created lazily, we need to make sure that
we lock around their creation.  Unfortunately, that means we need to
lock around every shareable object's call to `singleton_class`,
including classes and modules.

Safe multi-ractor subclass list mutation

We need to lock around mutation and accesses of a class's subclasses
list. Unfortunately we also need to do this when creating singleton
classes, as the singleton class does need to go into `super`'s
subclasses list for CC invalidation purposes.

Found by wbcheck

It seems like here the classext was associated with the class, but it
already had Ruby objects attached.

rb_gc_writebarrier_remember works around that issue, but I suspect if we
enabled autocompaction the values copied into the classext before it was
attached could be broken.

This reverts commit 2998c8d6b99ec49925ebea42198b29c3e27b34a7.

We need to find a better way to fix this bug. Even with this refcount
change, errors were still being seen in CI. For now we need to remove
this failing test.

We don't decrement the super and module subclasses count for iclasses that
are having their classext replaced. This causes the reference count to be
incorrect and leak memory.

The following script demonstrates the memory leak:

    module Foo
      refine(Object) do
        define_method(:<=) {}
      end
    end

    class Bar
      include Comparable
    end

With RUBY_FREE_AT_EXIT and ASAN, we can see many memory leaks, including:

    Direct leak of 16 byte(s) in 1 object(s) allocated from:
        #0 0x599f715adca2 in calloc (miniruby+0x64ca2)
        #1 0x599f716bd779 in calloc1 gc/default/default.c:1495:12
        #2 0x599f716d1370 in rb_gc_impl_calloc gc/default/default.c:8216:5
        #3 0x599f716b8ab1 in ruby_xcalloc_body gc.c:5221:12
        #4 0x599f716b269c in ruby_xcalloc gc.c:5215:34
        #5 0x599f715eab23 in class_alloc0 class.c:790:22
        #6 0x599f715e4bec in class_alloc class.c:836:12
        #7 0x599f715e60c9 in module_new class.c:1693:17
        #8 0x599f715e60a2 in rb_module_new class.c:1701:12
        #9 0x599f715e6303 in rb_define_module class.c:1733:14
        #10 0x599f715ebc5f in Init_Comparable compar.c:315:22
        #11 0x599f716e35f5 in rb_call_inits inits.c:32:5
        #12 0x599f7169cbfd in ruby_setup eval.c:88:9
        #13 0x599f7169cdac in ruby_init eval.c:100:17
        #14 0x599f715b0fa9 in rb_main main.c:41:5
        #15 0x599f715b0f59 in main main.c:62:12
        #16 0x739b2f02a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #17 0x739b2f02a28a in __libc_start_main csu/../csu/libc-start.c:360:3
        #18 0x599f7157c424 in _start (miniruby+0x33424)