[PATCH] reinit rb_internal_thread_event_hooks_rw_lock at fork

	[Bug #21959]

[Bug #21860]

If a thread was holding this lock before fork, it will not exist in the
child process. We should re-initialize these locks as we do with the VM
locks when forking.

Co-Authored-By: John Hawthorn <john@hawthorn.email>
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>

	[PATCH] fix last commit

	`th` is gone.

	[PATCH] `struct rb_thread_sched_waiting`

	Introduce `struct rb_thread_sched_waiting` and `timer_th.waiting`
	can contain other than `rb_thread_t`.

	[PATCH] mn timer thread: force wakeups for timeouts

[Bug #20633] Re-initialize vm->ractor.sched.lock after fork

Previously under certain conditions it was possible to encounter a
deadlock in the forked child process if ractor.sched.lock was held.

Co-authored-by: Nathan Froyd <froydnj@gmail.com>

	Ignore the result of pthread_kill in ubf_wakeup_thread

	After an upgrade to Ruby 3.3.0, I experienced reproducible production crashes
	of the form:

	[BUG] pthread_kill: No such process (ESRCH)

	This is the only pthread_kill call in Ruby. The result of pthread_kill was
	previously ignored in Ruby 3.2 and below. Checking the result was added in
	be1bbd5b7d40ad863ab35097765d3754726bbd54 (MaNy).

	I have not yet been able to create a minimal self-contained example,
	but it should be safe to remove the checks.

`hrrel / RB_HRTIME_PER_MSEC` floor the timeout value and it can
return wrong value by `Mutex#sleep` (return Integer even if
it should return nil (timeout'ed)).

This patch ceil the value and the issue was solved.

* Allows macOS users to use M:N threads (and technically FreeBSD, though it has not been verified on FreeBSD)

* Include sys/event.h header check for macros, and include sys/event.h when present

* Rename epoll_fd to more generic kq_fd (Kernel event Queue) for use by both epoll and kqueue

* MAP_STACK is not available on macOS so conditionall apply it to mmap flags

* Set fd to close on exec

* Log debug messages specific to kqueue and epoll on creation

* close_invalidate raises an error for the kqueue fd on child process fork. It's unclear rn if that's a bug, or if it's kqueue specific behavior

Use kq with rb_thread_wait_for_single_fd

* Only platforms with `USE_POLL` (linux) had changes applied to take advantage of kernel event queues. It needed to be applied to the `select` so that kqueue could be properly applied

* Clean up kqueue specific code and make sure only flags that were actually set are removed (or an error is raised)

* Also handle kevent specific errnos, since most don't apply from epoll to kqueue

* Use the more platform standard close-on-exec approach of `fcntl` and `FD_CLOEXEC`. The io-event gem uses `ioctl`, but fcntl seems to be the recommended choice. It is also what Go, Bun, and Libuv use

* We're making changes in this file anyways - may as well fix a couple spelling mistakes while here

Make sure FD_CLOEXEC carries over in dup

* Otherwise the kqueue descriptor should have FD_CLOEXEC, but doesn't and fails in assert_close_on_exec

`sched->lock_owner` can be non-NULL at fork because the timer thread
can acquire the lock while forking. `lock_owner` information is for
debugging, so we only need to clear it at fork.

I hope this patch fixes the following assertion failure:
```
thread_pthread.c:354:thread_sched_lock_:sched->lock_owner == NULL
```