Fix segfault crash observable with TCPSocket.open(nil, nil)

[Bug #21211]

Socket errors raised from background threads are hard to track down because
their backtrace starts from the spawned thread.

To solve this we can raise a new error with the old one as `cause`.

[Bug #21179]

```
socket.rb:1046:in 'Socket::HostnameResolutionStore#get_addrinfo': can not access non-shareable objects in constant
Socket::HostnameResolutionStore::PRIORITY_ON_V6 by non-main ractor. (Ractor::IsolationError)
	from socket.rb:724:in 'block in Socket.tcp_with_fast_fallback'
	from socket.rb:720:in 'Socket.tcp_with_fast_fallback'
```

	Do not save ResolutionError if resolution succeeds for any address family (#12678)

	* Do not save ResolutionError if resolution succeeds for any address family

	Socket with Happy Eyeballs Version 2 performs connection attempts and name resolution in parallel.

	In the existing implementation, if a connection attempt failed for one address family while name resolution was still in progress for the other, and that name resolution later failed, the method would terminate with a name resolution error.
	This behavior was intended to ensure that the final error reflected the most recent failure, potentially overriding an earlier error.

	However, [Bug #21088](https://bugs.ruby-lang.org/issues/21088) made me realize that terminating with a name resolution error is unnatural when name resolution succeeded for at least one address family.

	This PR modifies the behavior so that if name resolution succeeds for one address family, any name resolution error from the other is not saved.

	This PR includes the following changes:

	* Do not display select(2) as the system call that caused the raised error, as it is for internal processing

	* Fix bug: Get errno with Socket::SO_ERROR in Windows environment with a workaround for tests not passing

	[Bug #21092] Fallback variables after execonf has done

	When reading from a dummy makefile, the global variables initialized
	in `init_mkmf` may not be overridden.

`:nodoc:` seems not working for inner classes.

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