[PATCH] [Bug #21638] Mark ractor-local `$VERBOSE` and `$DEBUG`

	https://github.com/sampersand/blog/blob/master/the%20-s%20flag.md#the-segfault

Trigger postponed jobs on running_ec if that is available

	Currently, any postponed job triggered from a non-ruby thread gets sent
	to the main thread, but if the main thread is sleeping it won't be
	checking ints. Instead, we should try and interrupt running_ec if that's
	possible, and only fall back to the main thread if it's not.

	[Bug #20197]
	---
	 ractor.c | 16 ++++++++++++++++
	 1 file changed, 16 insertions(+)

rb_vm_main_ractor_ec was introduced to allow rb_postponed_job_* to work
when fired on non-Ruby threads, which have no EC set, and that is its
only use.

When RUBY_MN_THREADS=1 is set ractor->threads.running_ec is NULL when
the shared thread is sleeping. This instead grabs the EC directly from
the main thread which seems to always be set.

Fixes [Bug #20016]

Co-authored-by: Dustin Brown <dbrown9@gmail.com>

fix [Bug #19917]

`Ractor::Selector` is not approved by Matz so remove it from
Ruby-level.

The implementation is used by `Ractor.select` so most of implementation
was remaind and calling `rb_init_ractor_selector()`, `Ractor::Selector`
will be defined. I will provide `ractor-selector` gem to try it.

On 32-bit systems, we must store the shape ID in the gen_ivtbl to not
lose the shape. If we directly store the ST table into the generic
ivar table, then we lose the shape. This makes it impossible to
determine the shape of the object and whether it is too complex or not.

This patch introduce M:N thread scheduler for Ractor system.

In general, M:N thread scheduler employs N native threads (OS threads)
to manage M user-level threads (Ruby threads in this case).
On the Ruby interpreter, 1 native thread is provided for 1 Ractor
and all Ruby threads are managed by the native thread.

From Ruby 1.9, the interpreter uses 1:1 thread scheduler which means
1 Ruby thread has 1 native thread. M:N scheduler change this strategy.

Because of compatibility issue (and stableness issue of the implementation)
main Ractor doesn't use M:N scheduler on default. On the other words,
threads on the main Ractor will be managed with 1:1 thread scheduler.

There are additional settings by environment variables:

`RUBY_MN_THREADS=1` enables M:N thread scheduler on the main ractor.
Note that non-main ractors use the M:N scheduler without this
configuration. With this configuration, single ractor applications
run threads on M:1 thread scheduler (green threads, user-level threads).

`RUBY_MAX_CPU=n` specifies maximum number of native threads for
M:N scheduler (default: 8).

This patch will be reverted soon if non-easy issues are found.

[Bug #19842]