These tests use NM threads but NT is not freed for MN thread, causing it
to be reported as memory leaks in LSAN. For example:

    #1 0x62ee7bc67e99 in calloc1 gc/default/default.c:1495:12
    #2 0x62ee7bc7ba00 in rb_gc_impl_calloc gc/default/default.c:8216:5
    #3 0x62ee7bc631d1 in ruby_xcalloc_body gc.c:5221:12
    #4 0x62ee7bc5cdbc in ruby_xcalloc gc.c:5215:34
    #5 0x62ee7bdea4c6 in native_thread_alloc thread_pthread.c:2187:35
    #6 0x62ee7bdec31b in native_thread_check_and_create_shared thread_pthread_mn.c:429:39
    #7 0x62ee7bdea484 in native_thread_create_shared thread_pthread_mn.c:531:12
    #8 0x62ee7bdea1da in native_thread_create thread_pthread.c:2403:16
    #9 0x62ee7bdde2eb in thread_create_core thread.c:884:11
    #10 0x62ee7bde4466 in thread_initialize thread.c:992:16

* Added `Ractor::Port`
  * `Ractor::Port#receive` (support multi-threads)
  * `Rcator::Port#close`
  * `Ractor::Port#closed?`
* Added some methods
  * `Ractor#join`
  * `Ractor#value`
  * `Ractor#monitor`
  * `Ractor#unmonitor`
* Removed some methods
  * `Ractor#take`
  * `Ractor.yield`
* Change the spec
  * `Racotr.select`

You can wait for multiple sequences of messages with `Ractor::Port`.

```ruby
ports = 3.times.map{ Ractor::Port.new }
ports.map.with_index do |port, ri|
  Ractor.new port,ri do |port, ri|
    3.times{|i| port << "r#{ri}-#{i}"}
  end
end

p ports.each{|port| pp 3.times.map{port.receive}}

```

In this example, we use 3 ports, and 3 Ractors send messages to them respectively.
We can receive a series of messages from each port.

You can use `Ractor#value` to get the last value of a Ractor's block:

```ruby
result = Ractor.new do
  heavy_task()
end.value
```

You can wait for the termination of a Ractor with `Ractor#join` like this:

```ruby
Ractor.new do
  some_task()
end.join
```

`#value` and `#join` are similar to `Thread#value` and `Thread#join`.

To implement `#join`, `Ractor#monitor` (and `Ractor#unmonitor`) is introduced.

This commit changes `Ractor.select()` method.
It now only accepts ports or Ractors, and returns when a port receives a message or a Ractor terminates.

We removes `Ractor.yield` and `Ractor#take` because:
* `Ractor::Port` supports most of similar use cases in a simpler manner.
* Removing them significantly simplifies the code.

We also change the internal thread scheduler code (thread_pthread.c):
* During barrier synchronization, we keep the `ractor_sched` lock to avoid deadlocks.
  This lock is released by `rb_ractor_sched_barrier_end()`
  which is called at the end of operations that require the barrier.
* fix potential deadlock issues by checking interrupts just before setting UBF.

https://bugs.ruby-lang.org/issues/21262

TestThreadInstrumentation#test_sleeping_inside_ractor is a flaky and failing intermittently. Additionally, Launchable reported this test as a top flaky test. (Link: https://app.launchableinc.com/organizations/ruby/workspaces/ruby/insights/unhealthy-tests)

It failed only failed intermittently on ModGC workflow, so I'm gonna skip this test on ModGC workflow.

The test meant to assert the thread is suspended at least once,
but was actually asserting to it to be suspected at least twice.

Introduce `rb_thread_lock_native_thread()` to allocate dedicated
native thread to the current Ruby thread for M:N threads.
This C API is similar to Go's `runtime.LockOSThread()`.

Accepted at https://github.com/ruby/dev-meeting-log/blob/master/2023/DevMeeting-2023-08-24.md
(and missed to implement on Ruby 3.3.0)

... to disable a warning: assigned but unused variable - expected

It seems that the Ractor sleep GVL event arrives very slightly after the
value becomes available and other threads wake (which makes sense) so we
need a little additional time to ensure we end up in a consisteny state.

This reverts commit ad54fbf281ca1935e79f4df1460b0106ba76761e.

[Bug #20019]

This fixes GVL instrumentation in three locations it was missing:
- Suspending when blocking on a Ractor
- Suspending when doing a coroutine transfer from an M:N thread
- Resuming after an M:N thread starts

Co-authored-by: Matthew Draper <matthew@trebex.net>