Fix race condition right after ubf registration

	Fixes [Bug #21926]

    $ make test/ruby/test_thread.rb RUBYOPT=-w >/dev/null
    test/ruby/test_thread.rb:1595: warning: assigned but unused variable - bug21127

Mutexes were being improperly unlocked on thread cleanup. This bug was
introduced in 050a8954395.

We must keep a reference from the mutex to the thread, because if the fiber
is collected before the mutex is, then we cannot unlink it from the thread in
`mutex_free`. If it's not unlinked from the the thread when it's freed, it
causes bugs in `rb_thread_unlock_all_locking_mutexes`.

We now mark the fiber when a mutex is locked, and the thread is marked
as well. However, a fiber can still be freed in the same GC cycle as the
mutex, so the reference to the thread is still needed.

The reason we need to mark the fiber is that `mutex_owned_p()` has an ABA
issue where if the fiber is collected while it's locked, a new fiber could be
allocated at the same memory address and we could get false positives.

Fixes [Bug #21342]

Co-authored-by: John Hawthorn <john@hawthorn.email>

```
    1) Failure:
  TestThread#test_join_argument_conversion [D:/a/ruby/ruby/src/test/ruby/test_thread.rb:249]:
  Expected nil (oid=4) to be the same as #<TestThread::Thread:0x000001e9e13bbc18 D:/a/ruby/ruby/src/test/ruby/test_thread.rb:245 run> (oid=3856).
```
https://github.com/ruby/ruby/actions/runs/14636019219/job/41067199813?pr=13169

Previously, Ruby displayed backtraces for each thread on deadlock. However, it has not been shown since Ruby 3.0.
It should display the backtrace for debugging.

Co-authored-by: Jeremy Evans <code@jeremyevans.net>

Co-authored-by: "Nobuyoshi Nakada" <nobu@ruby-lang.org>

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]

The native thread ID can and does change on some operating systems (e.g.
Linux) after forking, so it needs to be re-queried.

[Bug #19873]

assert_in_out_err adds --disable=gems so we don't need to add
--disable-gems in the args list.