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]

Since it now live in the EC.

We're seeing an occasional crash on CI because this ends up inlined all
the way into ractor_wait_receive. On llvm (possibly other compilers) the
thread local address of ec ends up cached (not the value of ec, the
address ec is read from). So if we are migrated to another native
thread, that may be invalid.

Using rb_current_ec_noinline avoids this problems. It would be good to
adjust this code so that ec (or current ractor) is calculated once and
then passed through to both lock and unlock.

`pr` should not change on this method.

`T_DATA` has a flag `RUBY_TYPED_FROZEN_SHAREABLE` which means
if the `T_DATA` object is frozen, it can be sharable.
On the `Ractor.make_sharable(obj)`, rechable objects from the
`T_DATA` object will be apply `Ractor.make_shareable` recursively.

`RUBY_TYPED_FROZEN_SHAREABLE_NO_REC` is similar to the
`RUBY_TYPED_FROZEN_SHAREABLE`, but doesn't apply `Ractor.make_sharable`
recursively for children.
If it refers to unshareable objects, it will simply raise an error.

I'm not sure this pattern is common or not, so it is not in public.
If we find more cases, we can discuss publication.

The "EXIVAR" terminology has been replaced by "gen fields"
AKA "generic fields".

Exivar implies variable, but generic fields include more than
just variables, e.g. `object_id`.