Rarely, there are cases where a write(2) call from a child thread
to notify the main thread of the completion of name resolution fails.
If this happens while the main thread is waiting in `rb_thread_fd_select`,
rb_thread_fd_select may not notice that the name resolution has completed and end up hanging.

This issue becomes a problem when there are no sockets currently being connected,
no addresses ready for immediate connection attempts,
and name resolution has already completed for one address family
while the main thread is waiting for the name resolution of the other address family.
(If name resolution is not completed for either address family,
the chances of write(2) failing in both child threads are likely low.)

To avoid this issue, a timeout is introduced to rb_thread_fd_select under the above conditions.
This way, even if the issue occurs,
the completion of name resolution should still be detected
in the subsequent `if (!resolution_store.is_all_finished) ...` block.

Also, a topic about Socket::ResolutionError is added to NEWS

Wrap `do_fast_fallback_getaddrinfo` with `rb_thread_prevent_fork`

Referencing PR #10864,
wrap `do_fast_fallback_getaddrinfo` with `rb_thread_prevent_fork`
to avoid fork safety issues.

`do_fast_fallback_getaddrinfo` internally uses getaddrinfo(3),
leading to fork safety issues, as described in PR #10864.
This change ensures that `do_fast_fallback_getaddrinfo`
is guarded by `rb_thread_prevent_fork`,
preventing fork during its execution and avoiding related issues.

Since it's a singleton method, it should be referenced as `Socket.tcp_fast_fallback=`,
not `Socket#tcp_fast_fallback=`.

This change includes the following updates:
- Added an environment variable `RUBY_TCP_NO_FAST_FALLBACK` to control enabling/disabling fast_fallback
- Updated documentation and man pages
- Revised the implementation of Socket.tcp_fast_fallback= and Socket.tcp_fast_fallback, which previously performed dynamic name resolution of constants and variables. As a result, the following performance improvements were achieved:

(Case of 1000 executions of `TCPSocket.new` to the local host)

Rehearsal -----------------------------------------
before   0.031462   0.147946   0.179408 (  0.249279)
after    0.031164   0.146839   0.178003 (  0.346935)
-------------------------------- total: 0.178003sec

            user     system      total        real
before   0.027584   0.138712   0.166296 (  0.233356)
after    0.025953   0.127608   0.153561 (  0.237971)

Any memory allocated with xmalloc needs to be matched with xfree rather
than plain free.

Ruby unfortunately redefines strdup to be ruby_strdup, which uses
xmalloc so needs to be xfreed. Previously these were mismatched.

This commit changes the copy to be an explicit ruby_strdup (to avoid
confusion) and the free to be xfree.

* Use `rb_thread_fd_select` instead of select(2)

For fixing https://bugs.ruby-lang.org/issues/20932 .
`TCPSocket.new`, which internally uses select(2) for HEv2, can cause SEGV if the number of file descriptors exceeds `FD_SETSIZE`.
This change avoids that issue by replacing select(2) with `rb_thread_fd_select`, which is provided as part of Ruby's internal API.

---

This includes the following changes.

* rb_thread_fd_select does not need common pipe

The following two commits fix the proper clearing of the Connection Attempt Delay in `TCPSocket.new`.

- https://github.com/ruby/ruby/pull/12087/commits/b2f610b0edf8f84d9d0fce038f3ebfa9f2cb0223
- https://github.com/ruby/ruby/pull/12223/commits/6f4efaec5352cdeb6cab86036a83f53c9fa5c3d2

The same fix will be applied to `Socket.tcp`.

In some locations we were using shared->lock and in others
&shared->lock, and we were leaking the allocated memory.