Fixes [Bug #21266].

Backport of 9168cad4d63a5d281d443bde4edea6be213b0b25 to 3.3

	YJIT: End the block after OPTIMIZE_METHOD_TYPE_CALL (#13245)

	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>

`yjit-bindgen` isn't run to build Ruby releases at all, but people might
be running security scanners on the source tarball. Upgrade this
dependency to calm the scanners.

Backport of <https://github.com/ruby/ruby/pull/9652>.
See: <https://github.com/ruby/ruby/pull/10980>

If you start Ruby with `--yjit-disable`, the `+YJIT` shouldn't be
added until `RubyVM::YJIT.enable` is actually called. Otherwise
it's confusing in crash reports etc.

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

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>

This is a backport of 6c8ae44a388e5c03b7db90376af3652007b574e8 with a
test tailored to crash the 3.3.x branch (from GH-10904).

    Previously, we read the last element array even when the array was
    empty, doing an out-of-bounds access. This sometimes caused a SEGV.

    [Bug #20496]