`extra_fd` was leaked if `fd_set_cloexec` fails -- I can't think of any
chance of that happening here, but just in case.

Coverity Scan found this issue.

Check for nil like other callers of rb_fiber_scheduler_current().

So that it doesn't get included in the generated binaries for builds
that don't support loading shared GC modules

Co-Authored-By: Peter Zhu <peter@peterzhu.ca>

This reverts commit 6ea0dcc9781931129e77540097712f6196d49fde that was accidentally merged.

The main thread in a forked process appears not to own the read-write
lock.

Do not release GVL around get{pwuid,pwnam,grgid,grnam} calls,
as doing so is not thread-safe.  Another C extension could have
a concurrent call, and derefencing the returned pointer from
these calls could result in a segfault.

Have rb_home_dir_of call rb_getpwdirnam_for_login if available,
so it can use getpwnam_r and release GVL in a thread-safe manner.

This is related to GVL releasing work in [Bug #20587].

[Feature #20590]

For better of for worse, fork(2) remain the primary provider of
parallelism in Ruby programs. Even though it's frowned uppon in
many circles, and a lot of literature will simply state that only
async-signal safe APIs are safe to use after `fork()`, in practice
most APIs work well as long as you are careful about not forking
while another thread is holding a pthread mutex.

One of the APIs that is known cause fork safety issues is `getaddrinfo`.
If you fork while another thread is inside `getaddrinfo`, a mutex
may be left locked in the child, with no way to unlock it.

I think we could reduce the impact of these problem by preventing
in for the most notorious and common cases, by locking around
`fork(2)` and known unsafe APIs with a read-write lock.