Avoid opt_aset_with optimization inside multiple assignment

	Previously, since the opt_aset_with optimization was introduced,
	use of the opt_aset_with optimization inside multiple assignment
	would result in a segfault or incorrect instructions.

	Fixes [Bug #21012]

	Co-authored-by: Nobuyoshi Nakada <nobu.nakada@gmail.com>

	Fix next inside block argument stack underflow

	[Bug #20344]
	Fix compile_next adding removable adjust label

	Fix wrong unreachable chunk remove when jump destination label is unremovable

	[Bug #20468] Fix safe navigation in `for` variable

[Bug #20180]

Backports #9624.

[Bug #20569]

`putobject RubyVM::FrozenCore`, is not serializable, we
have to use `putspecialobject VM_SPECIAL_OBJECT_VMCORE`.

	GC guard catch_table_ary in iseq_set_exception_table

	The function iseq_set_exception_table allocates memory which can cause
	a GC compaction to run. Since catch_table_ary is not on the stack, it
	can be moved, which would make tptr incorrect.
	---
	 compile.c | 10 +++++++---
	 1 file changed, 7 insertions(+), 3 deletions(-)

Fix missing write barrier in iseq instruction list

[Bug #19880]

There's a missing write barrier for operands in the iseq instruction
list, which can cause crashes.

It can be reproduced when Ruby is compiled with `-DRUBY_DEBUG_ENV=1`.
Using the following command:

```
RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0 RUBY_DEBUG=gc_stress ruby -w --disable=gems -Itool/lib -W0 test.rb
```

The following script crashes:

```
require "test/unit"
```

	Remove ibf_dumper's WB_PROTECTED status

	It doesn't have the right write barriers in place. For example, there is

	    rb_mark_set(dump->global_buffer.obj_table);

	in the mark function, but there is no corresponding write barrier when
	adding to the table in the
	`ibf_dump_object() -> ibf_table_find_or_insert() -> st_insert()` code path.

	To insert write barrier correctly, we need to store the T_STRUCT VALUE
	inside `struct ibf_dump`. Instead of doing that, let's just demote it
	to WB unproected for correctness. These dumper object are ephemeral so
	there is not a huge benefit for having them WB protected.

	Users of the bootsnap gem ran into crashes due to this issue:
	https://github.com/Shopify/bootsnap/issues/436

	Fixes [Bug #19419]
	---
	 compile.c | 2 +-
	 1 file changed, 1 insertion(+), 1 deletion(-)

	Avoid checking interrupt when loading iseq
	MIME-Version: 1.0
	Content-Type: text/plain; charset=UTF-8
	Content-Transfer-Encoding: 8bit

	The interrupt check will unintentionally release the VM lock when loading an iseq.
	And this will cause issues with the `debug` gem's
	[`ObjectSpace.each_iseq` method](https://github.com/ruby/debug/blob/0fcfc28acae33ec1c08068fb7c33703cfa681fa7/ext/debug/iseq_collector.c#L61-L67),
	which wraps iseqs with a wrapper and exposes their internal states when they're actually not ready to be used.

	And when that happens, errors like this would occur and kill the `debug` gem's thread:

	```
	 DEBUGGER: ReaderThreadError: uninitialized InstructionSequence
	┃ DEBUGGER: Disconnected.
	┃ ["/opt/rubies/ruby-3.2.0/lib/ruby/gems/3.2.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:247:in `absolute_path'",
	┃  "/opt/rubies/ruby-3.2.0/lib/ruby/gems/3.2.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:247:in `block in iterate_iseq'",
	┃  "/opt/rubies/ruby-3.2.0/lib/ruby/gems/3.2.0/gems/debug-1.7.1/lib/debug/breakpoint.rb:246:in `each_iseq'",
	...
	```

	A way to reproduce the issue is to satisfy these conditions at the same time:

	1. `debug` gem calling `ObjectSpace.each_iseq` (e.g. [activating a `LineBreakpoint`](https://github.com/ruby/debug/blob/0fcfc28acae33ec1c08068fb7c33703cfa681fa7/lib/debug/breakpoint.rb#L246)).
	2. A large amount of iseq being loaded from another thread (possibly through the `bootsnap` gem).
	3. 1 and 2 iterating through the same iseq(s) at the same time.

	Because this issue requires external dependencies and a rather complicated timing setup to reproduce, I wasn't able to write a test case for it.
	But here's some pseudo code to help reproduce it:

	```rb
	require "debug/session"

	Thread.new do
	  100.times do
	    ObjectSpace.each_iseq do |iseq|
	      iseq.absolute_path
	    end
	  end
	end

	sleep 0.1

	load_a_bunch_of_iseq
	possibly_through_bootsnap
	```

	[Bug #19348]

	Co-authored-by: Peter Zhu <peter@peterzhu.ca>
	---
	 compile.c       |  2 +-
	 vm_core.h       |  1 +
	 vm_insnhelper.c | 11 +++++++++++
	 3 files changed, 13 insertions(+), 1 deletion(-)