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

This argument doesn't seem used anymore. Since we want to free these
objects during VM destruction when RUBY_FREE_AT_EXIT is set they must
work without an EC.

This avoids a use-after-free running `RUBY_FREE_AT_EXIT=1 ./miniruby -e ''`

Just removes the unneeded `prereg_` prefix from a few local var names.

for future extensions.

Our current implementation of rb_postponed_job_register suffers from
some safety issues that can lead to interpreter crashes (see bug #1991).
Essentially, the issue is that jobs can be called with the wrong
arguments.

We made two attempts to fix this whilst keeping the promised semantics,
but:
  * The first one involved masking/unmasking when flushing jobs, which
    was believed to be too expensive
  * The second one involved a lock-free, multi-producer, single-consumer
    ringbuffer, which was too complex

The critical insight behind this third solution is that essentially the
only user of these APIs are a) internal, or b) profiling gems.

For a), none of the usages actually require variable data; they will
work just fine with the preregistration interface.

For b), generally profiling gems only call a single callback with a
single piece of data (which is actually usually just zero) for the life
of the program. The ringbuffer is complex because it needs to support
multi-word inserts of job & data (which can't be atomic); but nobody
actually even needs that functionality, really.

So, this comit:
  * Introduces a pre-registration API for jobs, with a GVL-requiring
    rb_postponed_job_prereigster, which returns a handle which can be
    used with an async-signal-safe rb_postponed_job_trigger.
  * Deprecates rb_postponed_job_register (and re-implements it on top of
    the preregister function for compatability)
  * Moves all the internal usages of postponed job register
    pre-registration