[Bug #21779] Uniquify `InitVM` functions as well as `Init`

	Avoid possible name conflict when `--with-static-linked-ext`.

	[Bug #21779] Do not export InitVM functions

	Fix ruby/io-console#105.

	Fix redefinition of `clock_gettime` and `clock_getres`

	winpthreads-git 12.0.0.r720 provides `clock_gettime` and
	`clock_getres` as inline functions.

	Detect `clock_gettime` and `clock_getres` for winpthreads

**What does this PR do?**

This PR tweaks the `vm_push_frame` function to add an explicit compiler
fence (`atomic_signal_fence`) to ensure profilers that use signals
to interrupt applications (stackprof, vernier, pf2, Datadog profiler)
can safely sample from the signal handler.

This is a backport of #11036 to Ruby 3.3 .

**Motivation:**

The `vm_push_frame` was specifically tweaked in
https://github.com/ruby/ruby/pull/3296 to initialize the a frame
before updating the `cfp` pointer.

But since there's nothing stopping the compiler from reordering
the initialization of a frame (`*cfp =`) with the update of the cfp
pointer (`ec->cfp = cfp`) we've been hesitant to rely on this on
the Datadog profiler.

In practice, after some experimentation + talking to folks, this
reordering does not seem to happen.

But since modern compilers have a way for us to exactly tell them
not to do the reordering (`atomic_signal_fence`), this seems even
better.

I've actually extracted `vm_push_frame` into the "Compiler Explorer"
website, which you can use to see the assembly output of this function
across many compilers and architectures: https://godbolt.org/z/3oxd1446K

On that link you can observe two things across many compilers:
1. The compilers are not reordering the writes
2. The barrier does not change the generated assembly output
   (== has no cost in practice)

**Additional Notes:**

The checks added in `configure.ac` define two new macros:
* `HAVE_STDATOMIC_H`
* `HAVE_DECL_ATOMIC_SIGNAL_FENCE`

Since Ruby generates an arch-specific `config.h` header with
these macros upon installation, this can be used by profilers
and other libraries to test if Ruby was compiled with the fence enabled.

**How to test the change?**

As I mentioned above, you can check https://godbolt.org/z/3oxd1446K
to confirm the compiled output of `vm_push_frame` does not change
in most compilers (at least all that I've checked on that site).

	[Bug #20499] Use Xcode owned tools for Xcode clang

	Xcode has its own version tools that may be incompatible with genuine
	LLVM tools, use the tools in the same directory.

	[Bug #20500] Search non-default directories for jemalloc

	Co-Authored-by: lish82 (Hiroki Katagiri)

	[Bug #20494] Search non-default directories for GMP

	Co-Authored-by: lish82 (Hiroki Katagiri)

[Bug #20085] Use consistent default options for `-mbranch-protection`

We need to use the same options for both C compiler and assembler
when `-mbranch-protection` is guessed by configure. Otherwise,
`coroutine/arm64/Context.{h,S}` will use incompatible PAC strategies.

* 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

Previously, the embedded semicolon in BASERUBY if BASERUBY is
not available breaks tarball builds without BASERUBY when using
OpenBSD make, due to the inability to escape MFLAGS correctly.
This moves the same BASERUBY code into a separate file, avoiding
the MFLAGS quoting issue.

BASERUBY must be passed to build-ext because it is required
by ripper since the introduction of lrama.

Fixes [Bug #19683]

Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>