Fixes [Bug #21266].

Backport of 9168cad4d63a5d281d443bde4edea6be213b0b25 to 3.3

[Bug #21860]

If a thread was holding this lock before fork, it will not exist in the
child process. We should re-initialize these locks as we do with the VM
locks when forking.

Co-Authored-By: John Hawthorn <john@hawthorn.email>
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>

	Fix Symbol#to_proc (rb_sym_to_proc) to be ractor safe

	In non-main ractors, don't use `sym_proc_cache`. It is not thread-safe
	to add to this array without a lock and also it leaks procs from one
	ractor to another. Instead, we create a new proc each time. If this
	results in poor performance we can come up with a solution later.

	Fixes [Bug #21354]

	YJIT: Fix potential infinite loop when OOM (GH-13186)

	Avoid generating an infinite loop in the case where:
	1. Block `first` is adjacent to block `second`, and the branch from `first` to
	   `second` is a fallthrough, and
	2. Block `second` immediately exits to the interpreter, and
	3. Block `second` is invalidated and YJIT is OOM

	While pondering how to fix this, I think I've stumbled on another related edge case:
	1. Block `incoming_one` and `incoming_two` both branch to block `second`. Block
	   `incoming_one` has a fallthrough
	2. Block `second` immediately exits to the interpreter (so it starts with its exit)
	3. When Block `second` is invalidated, the incoming fallthrough branch from
	   `incoming_one` might be rewritten first, which overwrites the start of block
	   `second` with a jump to a new branch stub.
	4. YJIT runs of out memory
	5. The incoming branch from `incoming_two` is then rewritten, but because we're
	   OOM we can't generate a new stub, so we use `second`'s exit as the branch
	   target. However `second`'s exit was already overwritten with a jump to the
	   branch stub for `incoming_one`, so `incoming_two` will end up jumping to
	   `incoming_one`'s branch stub.

	Fixes [Bug #21257]

Evident with the crash reported in [Bug #20997], the C replacement
codegen functions aren't authored to handle block arguments (nor
should they because the extra code from the complexity defeats
optimization). Filter sites with VM_CALL_ARGS_BLOCKARG.

Co-Authored-By: Alan Wu <alanwu@ruby-lang.org>

[Bug #20633] Re-initialize vm->ractor.sched.lock after fork

Previously under certain conditions it was possible to encounter a
deadlock in the forked child process if ractor.sched.lock was held.

Co-authored-by: Nathan Froyd <froydnj@gmail.com>

Don't call `Warning.warn` unless the category is enabled

The warning category should be enabled if we want to call
`Warning.warn`.

This commit speeds up the following benchmark:

```ruby
eval "def test; " +
  1000.times.map { "'  '.chomp!" }.join(";") + "; end"

def run_benchmark count
  i = 0
  while i < count
    start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
    yield
    ms = Process.clock_gettime(Process::CLOCK_MONOTONIC) - start
    puts "itr ##{i}: #{(ms * 1000).to_i}ms"
    i += 1
  end
end

run_benchmark(25) do
  250.times do
    test
  end
end
```

On `master` this runs at about 92ms per iteration. With this patch, it
is 7ms per iteration.

[Bug #20573]

	Improve YJIT performance warning regression test

	[Bug #20522]

Do not emit shape transition warnings when YJIT is compiling

[Bug #20522]

If `Warning.warn` is redefined in Ruby, emitting a warning would invoke
Ruby code, which can't safely be done when YJIT is compiling.

Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>