Only emit circular dependency warning for owned thread shields [Bug
	 #19415]

	If multiple threads attemps to load the same file concurrently
	it's not a circular dependency issue.

	So we check that the existing ThreadShield is owner by the current
	fiber before warning about circular dependencies.
	---
	 internal/thread.h                                     |  1 +
	 load.c                                                |  3 ++-
	 spec/ruby/core/kernel/shared/require.rb               | 11 +++++++++++
	 spec/ruby/fixtures/code/concurrent_require_fixture.rb |  4 ++++
	 test/ruby/test_require.rb                             |  3 ---
	 thread.c                                              | 11 +++++++++++
	 6 files changed, 29 insertions(+), 4 deletions(-)
	 create mode 100644 spec/ruby/fixtures/code/concurrent_require_fixture.rb

	Use Thread.pass until thread.stop? to wait for thread to block

	[Bug #19415]

	It should be more reliable
	---
	 spec/ruby/fixtures/code/concurrent_require_fixture.rb | 2 +-
	 1 file changed, 1 insertion(+), 1 deletion(-)

Previously, for statically-linked extensions, we used
`vm->loading_table` to delay calling the init function until the
extensions are required. This caused the extensions to look like they
are in the middle of being loaded even before they're required.
(`rb_feature_p()` returned true with a loading path output.) Combined
with autoload, queries like `defined?(CONST)` and `Module#autoload?`
were confused by this and returned nil incorrectly. RubyGems uses
`defined?` to detect if OpenSSL is available and failed when OpenSSL was
available in builds using `--with-static-linked-ext`.

Use a dedicated table for the init functions instead of adding them to
the loading table. This lets us remove some logic from non-EXTSTATIC
builds.

[Bug #19115]

We use this code path when we require the same extension twice, so it's
not necessarily about the feature being statically linked. Removing this
code when there is no statically linked extensions leads to breakage.

This patch pushes dummy frames when loading code for the
profiling purpose.

The following methods push a dummy frame:
* `Kernel#require`
* `Kernel#load`
* `RubyVM::InstructionSequence.compile_file`
* `RubyVM::InstructionSequence.load_from_binary`

https://bugs.ruby-lang.org/issues/18559

rb_ary_tmp_new suggests that the array is temporary in some way, but
that's not true, it just creates an array that's hidden and not on the
transient heap. This commit renames it to rb_ary_hidden_new.

[Misc #18891]

darray was used in YJIT which required the functions to not trigger GC.
YJIT has now moved to Rust and does not use darray anymore, so we can
remove the functions that don't trigger GC and only keep the ones that
trigger GC.