Example insns diff for `def x = [3]; def a(...) = b(*x, 2, 3, ...)`

     == disasm: #<ISeq:a@-e:1 (1,13)-(1,42)>
     local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
     [ 1] "..."@0
     0000 putself                                                          (   1)[Ca]
     0000 putself
     0000 opt_send_without_block                 <calldata!mid:x, argc:0, FCALL|VCALL|ARGS_SIMPLE>
     0000 splatarray                             true
     0000 putobject                              2
     0000 putobject                              3
    +0000 pushtoarray                            2
     0000 getlocal_WC_0                          "..."@0
     0000 sendforward                            <calldata!mid:b, argc:1, ARGS_SPLAT|ARGS_SPLAT_MUT|FCALL|FORWARDING>, nil
     0000 leave                                  [Re]

This matches the insns produced by parse.y

	[PATCH] Fix compilation for forwarding params in Prism

	[Bug #21326]

Basically a redo of https://github.com/ruby/ruby/commit/a1403fb7cbd1fe0df97c932be9814c86081783dc
but respecting the frozen string literal magic comment

Fixes [Bug #21187]

Strings concatenated with backslash may end up being frozen when they
shouldn't be.  This commit fixes the issue.  It required a change
upstream in Prism, but also a change to the Prism compiler in CRuby.

  https://github.com/ruby/prism/pull/3606

[Bug #21187]

	[PATCH] Correctly compile splats in for-loop index in prism

	Fixes [Bug #21648]

	This is a followup to https://github.com/ruby/ruby/pull/13597.
	The added test passed but didn't emit the same instructions.

	This also handles bare splats and aligns instructions for all cases

The following is crashing for me:

```shell
ruby --yjit --yjit-call-threshold=1 -e '1.tap { raise rescue p it }'

ruby: YJIT has panicked. More info to follow...
thread '<unnamed>' panicked at ./yjit/src/codegen.rs:2402:14:
...
```

It seems `it` sometimes points to the wrong value:

```shell
ruby -e '1.tap { raise rescue p it }'
false

ruby -e '1.tap { begin; raise; ensure; p it; end } rescue nil'
false
```

But only when `$!` is set:

```shell
ruby -e '1.tap { begin; nil; ensure; p it; end }'
1

ruby -e '1.tap { begin; nil; rescue; ensure; p it; end }'
1

ruby -e '1.tap { begin; raise; rescue; ensure; p it; end }'
1
```

Prism can parse multiple versions of ruby. Because of that branch release managers are ok with simply
bumping prism to its latest version.

However, if no version is specified, it will parse as the latest known version, which can be ahead of the maintenance branch.
So we need to explicitly pass a version to not accidentally introduce new syntax to maintenance branches.

Found by wbcheck

The purpose of this commit is to fix Bug #21188.  We need to detect when
stdin has run in to an EOF case.  Unfortunately we can't _call_ the eof
function on IO because it will block.

Here is a short script to demonstrate the issue:

```ruby
x = STDIN.gets
puts x
puts x.eof?
```

If you run the script, then type some characters (but _NOT_ a newline),
then hit Ctrl-D twice, it will print the input string.  Unfortunately,
calling `eof?` will try to read from STDIN again causing us to need a
3rd Ctrl-D to exit the program.

Before introducing the EOF callback to Prism, the input loop looked
kind of like this:

```ruby
loop do
  str = STDIN.gets
  process(str)

  if str.nil?
    p :DONE
  end
end
```

Which required 3 Ctrl-D to exit.  If we naively changed it to something
like this:

```ruby
loop do
  str = STDIN.gets
  process(str)

  if STDIN.eof?
    p :DONE
  end
end
```

It would still require 3 Ctrl-D because `eof?` would block.  In this
patch, we're wrapping the IO object, checking the buffer for a newline
and length, and then using that to simulate a non-blocking eof? method.

This commit wraps STDIN and emulates a non-blocking `eof` function.

[Backport #21188]

	Fix flipflop line numbers

	[ruby-core:121605]