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(-)

[Feature #19134]

With this change, we're storing the iv name on an inline cache on
setinstancevariable instructions. This allows us to check the inline
cache to count instance variables set in initialize and give us an
estimate of iv capacity for an object.

For the purpose of estimating the number of instance variables required
for an object, we're assuming that all initialize methods will call
`super`.

This change allows us to estimate the number of instance variables
required without disassembling instruction sequences.

Co-Authored-By: Aaron Patterson <tenderlove@ruby-lang.org>

This was introduced by b609bdeb5307e280137b4b2838af0fe4e4b46f1c
to suppress warnings. However these warngins were deleted by
beae6cbf0fd8b6619e5212552de98022d4c4d4d4. Therefore these codes
are not needed anymore.

`throw TAG_BREAK` instruction makes a jump only if the continuation of
catch of TAG_BREAK exactly matches the instruction immediately following
the "send" instruction that is currently being executed. Otherwise, it
seems to determine break from proc-closure.

Branch coverage may insert some recording instructions after "send"
instruction, which broke the conditions for TAG_BREAK to work properly.

This change forces to set the continuation of catch of TAG_BREAK
immediately after "send" (or "invokesuper") instruction.

[Bug #18991]

This patch pushes dummy frames when loading code for the
profiling purpose.

The following methods push a dummy frame:
* `Kernel#require`
* `Kernel#load`
* `RubyVM::InstructionSequence.compile_file`
* `RubyVM::InstructionSequence.load_from_binary`

https://bugs.ruby-lang.org/issues/18559

This reverts commit 9a6803c90b817f70389cae10d60b50ad752da48f.

This reverts commit 68bc9e2e97d12f80df0d113e284864e225f771c2.