YJIT: Filter `&` calls from specialized C method codegen

	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.

Fix unused_mut Rust warnings

Rust version 1.71.0 and up issue these warnings. On GitHub CI, the
warnings were previously seen in -DYJIT_FORCE_ENABLE runs.

	YJIT: Fix false object collection when setting ivar

	Previously, setinstancevariable could generate code that calls
	`rb_ensure_iv_list_size()` without first updating `cfp->sp`. This means
	in the event that a GC start from within said routine the top few
	objects would not be marked, causing them to be falsly collected.

	Call `jit_prepare_routine_call()` first.

	[Bug #19601]
	---
	 bootstraptest/test_yjit.rb | 20 ++++++++++++++++++++
	 yjit/src/codegen.rs        |  5 +++++
	 2 files changed, 25 insertions(+)

	YJIT: Remove duplicate `asm.spill_temps()`

	`jit_prepare_routine_call()` calls it, and there is another call above on line 2302.

	Co-authored-by: Takashi Kokubun <takashikkbn@gmail.com>
	---
	 yjit/src/codegen.rs | 1 -
	 1 file changed, 1 deletion(-)

	YJIT: Fix missing argc check in known cfuncs

	Previously we were missing a compile-time check that the known cfuncs
	receive the correct number of arguments.

	We noticied this because in particular when using ARGS_SPLAT, which also
	wasn't checked, YJIT would crash on code which was otherwise correct
	(didn't raise exceptions in the VM).

	This still supports vararg (argc == -1) cfuncs. I added an additional
	assertion that when we use the specialized codegen for one of these
	known functions that the argc are popped off the stack correctly, which
	should help ensure they're implemented correctly (previously the crash
	was usually observed on a future `leave` insn).

	[Bug #19595]
	---
	 bootstraptest/test_yjit.rb | 32 ++++++++++++++++++++++++++++++++
	 yjit/src/codegen.rs        |  4 +++-
	 2 files changed, 35 insertions(+), 1 deletion(-)

	YJIT: Protect strings from GC on String#<< (#7466)

	Fix https://github.com/Shopify/yjit/issues/310

	[Bug #19483]

	Co-authored-by: Maxime Chevalier-Boisvert <maxime.chevalierboisvert@shopify.com>
	Co-authored-by: Jimmy Miller <jimmy.miller@shopify.com>
	---
	 yjit/src/codegen.rs | 3 +++
	 1 file changed, 3 insertions(+)

	YJIT: Save PC on rb_str_concat (#7586)

	[Bug #19483]

	Co-authored-by: Alan Wu <alansi.xingwu@shopify.com>
	---
	 test/ruby/test_yjit.rb | 19 +++++++++++++++++++
	 yjit/src/codegen.rs    |  6 ++++--
	 2 files changed, 23 insertions(+), 2 deletions(-)

	YJIT: Generate Block::entry_exit with block entry PC

	Previously, when Block::entry_exit is requested from any instruction
	that is not the first one in the block, we generated the exit with an
	incorrect PC. We should always be using the PC for the entry of the
	block for Block::entry_exit.

	It was a simple typo. The bug was [introduced][1] while we were
	refactoring to use the current backend. Later, we had a chance to spot
	this issue while [preparing][2] to enable unused variable warnings, but
	didn't spot the issue.

	Fixes [Bug #19463]

	[1]: 27fcab995e6dde19deb91dc6e291bdb72100af68
	[2]: 31461c7e0eab4963ccc8649ea8ebf27979132c0c
	---
	 test/ruby/test_yjit.rb | 41 +++++++++++++++++++++++++++++++++++++++++
	 yjit/src/codegen.rs    |  4 ++--
	 2 files changed, 43 insertions(+), 2 deletions(-)

YJIT: Fix autosplat miscomp for blocks with optionals

When passing an array as the sole argument to `yield`, and the yieldee
takes more than 1 optional parameter, the array is expanded similar
to `*array` splat calls. This is called "autosplat" in
`setup_parameters_complex()`.

Previously, YJIT did not detect this autosplat condition. It passed the
array without expanding it, deviating from interpreter behavior.
Detect this conditon and refuse to compile it.

The class variable cache that was added in
https://github.com/ruby/ruby/pull/4544 changed the behavior of class
variables on cloned classes. As reported when a class is cloned AND a
class variable was set, and the class variable was read from the
original class, reading a class variable from the cloned class would
return the value from the original class.

This was happening because the IC (inline cache) is stored on the ISEQ
which is shared between the original and cloned class, therefore they
share the cache too.

To fix this we are now storing the `cref` in the cache so that we can
check if it's equal to the current `cref`. If it's different we don't
want to read from the cache. If it's the same we do. Cloned classes
don't share the same cref with their original class.

This will need to be backported to 3.1 in addition to 3.2 since the bug
exists in both versions.

We also added a marking function which was missing.

Fixes [Bug #19379]

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