[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]

	[PATCH] [Bug #21819] Data objects without members should also be frozen

	[PATCH] [Bug #21814] Fix negative bignum modulo

	If modulo is zero, do not  apply bias even if the divisor is zero.
	`BIGNUM_POSITIVE_P` is true even on bignum zero.

When requiring a file like "benchmark/ips", the warning system would
incorrectly warn about the "benchmark" gem not being a default gem,
even when the user has "benchmark-ips" (a separate third-party gem)
in their Gemfile.

The fix checks if a hyphenated version of the require path exists in
the bundle specs before issuing a warning. For example, requiring
"benchmark/ips" now checks for both "benchmark" and "benchmark-ips"
in the Gemfile.

[Bug #21828]

Without this change, classes (including iclass) are allocated
as un-boxable classes after initializing user boxes (after starting
script evaluation). Under this situation, iclasses are created as
un-boxabled class when core modules are included by a class in the
root box, then it causes problems because it's in the root box but
it can't have multiple classexts.

This change makes it possible to allocate boxable classes even after
initializing user boxes. Classes create in the root box will be
boxable, and those can have 2 or more classexts.

This reverts commit 31ff07ed1eb05d01f7da3c017d542137a3db1e94.

* Don't add a test which only runs on production release
  * https://github.com/ruby/actions/actions/runs/20486784889/job/58870959976
* Don't add a new line to `ruby --help`
  * https://github.com/ruby/ruby/pull/14142#issuecomment-3689829564

This reverts commit 9b576cd6255aba97e5e2f55f4b09f00c7dd0e839.

`Dir.mktmpdir` concatenates a random base-36 number separated by "-",
so may generate pathnames containing "-j2".