The cc_entries list associated with the invalidated CME can be deleted
from the table during GC, so it isn't safe to copy (and we shouldn't
copy it anyways, it's stale data).

This is easier to access as ec->ractor_id instead of pointer-chasing through
ec->thread->ractor->ractor_id

Co-authored-by: Luke Gruber <luke.gru@gmail.com>

Before this change, GC'ing any Ractor object caused you to lose all
enabled tracepoints across all ractors (even main). Now tracepoints are
ractor-local and this doesn't happen. Internal events are still global.

Fixes [Bug #19112]

This rewrites the class allocator search to be faster. Instead of using
RCLASS_SUPER, which is now even slower due to Box, we can scan the
superclasses list to find a class where the allocator is defined.

This also disallows allocating from an ICLASS. Previously I believe that
was only done for FrozenCore, and that was changed in
e596cf6e93dbf121e197cccfec8a69902e00eda3.

Previously, this didn't work correctly, resulting in a
SystemStackError. This fixes the issue by finding the related
superclass method entry, and updating the orig_me in the
refinement method to point to the superclass method.

Fixes [Bug #21446]

When defining a bmethod, we recorded the current Ractor's object in the
method. However that was never marked and so could be GC'd and reused by
a future Ractor. Instead we can use the Ractor's id, which we expect to
be unique forever.

Co-authored-by: Luke Gruber <luke.gru@gmail.com>

invalidate_ccs_in_iclass_cc_tbl deletes the ccs from the table but never
frees it, causing memory to leak.

A method defined in a module has no `defined_class`, use the ICLASS
for it as the `defined_class`.