Push a real iseq in rb_vm_push_frame_fname()

	Previously, vm_make_env_each() (used during proc
	creation and for the debug inspector C API) picked up the
	non-GC-allocated iseq that rb_vm_push_frame_fname() creates,
	which led to a SEGV when the GC tried to mark the non GC object.

	Put a real iseq imemo instead. Speed should be about the same since
	the old code also did a imemo allocation and a malloc allocation.

	Real iseq allows ironing out the special-casing of dummy frames in
	rb_execution_context_mark() and rb_execution_context_update(). A check
	is added to RubyVM::ISeq#eval, though, to stop attempts to run dummy
	iseqs.

	[Bug #21180]

	Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>

	Ensure fiber scheduler re-acquires mutex when interrupted from sleep. (#12158)

	[Bug #20907]

If one thread is reading and another closes that socket, the close
blocks waiting for the read to abort cleanly. This ensures that Ruby is
totally done with the file descriptor _BEFORE_ we tell the OS to close
and potentially re-use it.

When the read is correctly terminated, the close should be unblocked.
That currently works if closing is happening on a thread, but if it's
happening on a fiber with a fiber scheduler, it does NOT work.

This patch ensures that if the close happened in a fiber scheduled
thread, that the scheduler is notified that the fiber is unblocked.

[Bug #20723]

	Enumerator should use a non-blocking fiber, change `rb_fiber_new` to be non-blocking by default. (#10481)

rsock_raise_socket_error is called only when getaddrinfo and getaddrname fail

test/fiber/test_queue.rb: Make the stuck tests fail.

We observed the 2 tests in the `test/fiber/test_queue.rb` getting stuck
in some GCC compilers in Ubuntu ppc64le focal/jammy, even when the timeout
`queue.pop(timeout: 0.0001)` is set in the code.

This commit is to make the tests fail rather than getting stuck.

It should not be hidden, since it can be grabbed by a fiber scheduler.

`ppc64le` appears to be struggling with this test due to timeout. Let's see
if reducing the number of iterations can help improve the test performance.