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>

Previously when using a JIT and Ractors at the same time with debug
assertions turned on this could rarely fail with:

    vm_core.h:1448: Assertion Failed: VM_ENV_FLAGS:FIXNUM_P(flags)

When using Ractors, any time the VM lock is acquired, that may join a
barrier as another Ractor initiates GC. This could be made to happen
reliably by replacing the invalidation with a call to rb_gc().

This assertion failure happens because

    VM_STACK_ENV_WRITE(ep, 0, (VALUE)env);

Is setting VM_ENV_DATA_INDEX_FLAGS to the environment, which is not a
valid set of flags (it should be a fixnum). Although we update cfp->ep,
rb_execution_context_mark will also mark the PREV_EP, and until the
recursive calls to vm_make_env_each all finish the "next" ep may still
be pointing to the stack env we've just escaped.

I'm not completely sure why we need to store this on the stack - why is
setting cfp->ep not enough? I'm also not sure why
rb_execution_context_mark needs to mark the prev_ep.

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]

[Bug #21775]

Internal tracepoints only make sense to run globally, and they already
took completely different paths.

This will help JITs (and maybe later the interpreter) optimize
Integer#>>.

This reverts commit 26a9e0b4e31f7b5a9cbd755e0a15823a8fa51bae partially.