[Bug #20915] Fix SEGV with `TracePoint#parameters` and aliased C method

	The following snippet results with a SEGV:

	```ruby
	C = Class.new do
	  alias_method :new_to_s, :to_s
	end

	TracePoint.new(:c_call, &:parameters).enable { C.new.new_to_s }
	```

	at MRI 3.3.6 and ruby 3.4.0dev

	The root cause of the issue lies in the `rb_tracearg_parameters` function
	within the `RUBY_EVENT_C_RETURN` branch. Specifically, when the invoked
	method is an alias for a C function,
	`rb_method_entry_without_refinements(..., trace_arg->called_id, ...)`
	may return NULL. In that case we can fallback to `trace_arg->id`.

	Memory leak with TracePoint on bmethod

	[Bug #20194]

	When disabling the TracePoint on bmethod, the hooks list is not freed.

	For example:

	    obj = Object.new
	    obj.define_singleton_method(:foo) {}
	    bmethod = obj.method(:foo)
	    tp = TracePoint.new(:return) {}

	    10.times do
	      100_000.times do
	        tp.enable(target: bmethod) {}
	      end

	      puts `ps -o rss= -p #{$$}`
	    end

	Before:

	    18208
	    22832
	    26528
	    29728
	    34000
	    37776
	    40864
	    44400
	    47680
	    51504

	After:

	    16688
	    17168
	    17168
	    17248
	    17696
	    17760
	    17824
	    17824
	    17856
	    17920
	---
	 test/ruby/test_settracefunc.rb | 13 +++++++++++++
	 vm_trace.c                     |  1 +
	 2 files changed, 14 insertions(+)

	Fix crash in TracePoint c_call for removed method

	trace_arg->id is the ID of the original method of an aliased method. If
	the original method is removed, then the lookup will fail. We should use
	trace_arg->called_id instead, which is the ID of the aliased method.

	Fixes [Bug #19305]
	---
	 test/ruby/test_settracefunc.rb | 23 +++++++++++++++++++++++
	 vm_trace.c                     |  2 +-
	 2 files changed, 24 insertions(+), 1 deletion(-)

I noticed this while running test_yjit with --mjit-call-threshold=1, 
which redefines `Integer#<`. When Ruby is monkey-patched, 
MJIT itself could be broken.

Similarly, Ruby scripts could break MJIT in many different ways. I
prepared the same set of hooks as YJIT so that we could possibly
override it and disable it on those moments. Every constant under
RubyVM::MJIT is private and thus it's an unsupported behavior though.

This makes sure the method returns nil for these events, as
described in NEWS, even if the TracePoint could create a binding.

It seems more readable to put JIT invalidation code together.

Follow-up for 2b8191bdad7545b71f270d2b25a34cd2b3afa02f. Since that
commit, we stopped doing code invalidation the second time the call and
return events are enabled. We need to do it every time these events are
enabled because we might have generated code while these events are
disabled.

Also rename locals and edit comments to make it more clear that the iseq
rewrite code path only happens the first time a particular iseq trace
event is enabled.

[Misc #18891]