Fix race condition right after ubf registration

	Fixes [Bug #21926]

	[PATCH] Fix sleep spurious wakeup from sigchld (#15802)

	When sleeping with `sleep`, currently the main thread can get woken up from sigchld
	from any thread (subprocess exited). The timer thread wakes up the main thread when this
	happens, as it checks for signals. The main thread then executes the ruby sigchld handler
	if one is registered and is supposed to go back to sleep immediately. This is not ideal but
	it's the way it's worked for a while. In commit 8d8159e7d8 I added writes to `th->status`
	before and after `wait_running_turn` in `thread_sched_to_waiting_until_wakeup`, which is
	called from `sleep`. This is usually the right way to set the thread's status, but `sleep`
	is an exception because the writes to `th->status` are done in `sleep_forever`. There's a
	loop that checks `th->status` in `sleep_forever`. When the main thread got woken up from
	sigchld it saw the changed `th->status` and continued to run the main thread instead of
	going back to sleep.

	The following script shows the error. It was returning instead of sleeping forever.

	```ruby
	t = Thread.new do
	  sleep 0.3
	  `echo hello`  # Spawns subprocess
	  puts "Subprocess exited"
	end

	puts "Main thread sleeping..."
	result = sleep  # Should block forever
	puts "sleep returned: #{result.inspect}"
	```

	Fixes [Bug #21812]

`thread_sched_to_waiting_common0` is no longer needed.

Fix typo in thread_pthread.c: threre -> there

Fix race between timer thread dequeuing waiting thread and thread
skipping sleeping due to being dequeued. We now use `th->event_serial` which
is protected by `thread_sched_lock`. When a thread is put on timer thread's waiting
list, the event serial is saved on the item. The timer thread checks
that the saved serial is the same as current thread's serial before
calling `thread_sched_to_ready`.

The following script (taken from a test in `test_thread.rb` used to crash on
scheduler debug assertions. It would likely crash in non-debug mode as well.

```ruby
def assert_nil(val)
  if val != nil
    raise "Expected #{val} to be nil"
  end
end

def assert_equal(expected, actual)
  if expected != actual
    raise "Expected #{expected} to be #{actual}"
  end
end

def test_join2
  ok = false
  t1 = Thread.new { ok = true; sleep }
  Thread.pass until ok
  Thread.pass until t1.stop?
  t2 = Thread.new do
    Thread.pass while ok
    t1.join(0.01)
  end
  t3 = Thread.new do
    ok = false
    t1.join
  end
  assert_nil(t2.value)
  t1.wakeup
  assert_equal(t1, t3.value)
ensure
  t1&.kill&.join
  t2&.kill&.join
  t3&.kill&.join
end

rs = 30.times.map do
  Ractor.new do
    test_join2
  end
end
rs.each(&:join)
```

This race condition was found when calling `Thread#join` with a timeout
inside a ractor. The race is between the polling thread waking up the
thread and the `ubf` getting called (`ubf_event_waiting`). The error was
that the ubf or polling thread would set the thread as ready, but then
the other function would do the same.

Fixes [Bug #21614]

This is useful for debugging mutex issues as it increases contention for locks.
It is off by default.

We allocate the stack of the main thread using malloc, but we never set
malloc_stack to true and context_stack. If we fork, the main thread may
no longer be the main thread anymore so it reports memory being leaked
in RUBY_FREE_AT_EXIT.

This commit allows the main thread to free its own VM stack at shutdown.