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

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

[Feature #18774]

As well as `SizedQueue#pop(timeout: sec)`

If both `non_block=true` and `timeout:` are supplied, ArgumentError
is raised.

Previously, we didn't pop the frame that runs the TracePoint hook for
b_return events for blocks running as methods (bmethods). In case the
hook raises, that formed an infinite loop during stack unwinding in
hook_before_rewind().

[Bug #18060]

df317151a5b4e0c5a30fcc321a9dc6abad63f7ed removed the code to free
rb_hook_list_t, so repeated targeting of the same bmethod started
to leak the hook list. You can observe how the maximum memory use
scales with input size in the following script with `/usr/bin/time -v`.

```ruby
o = Object.new
o.define_singleton_method(:foo) {}
trace = TracePoint.new(:return) {}

bmethod = o.method(:foo)

ARGV.first.to_i.times { trace.enable(target:bmethod){} }
4.times {GC.start}
```

After this change the maximum doesn't grow as quickly.

To plug the leak, check whether the hook list is already allocated
when enabling the targeting TracePoint for the bmethod. This fix
also allows multiple TracePoints to target the same bmethod, similar
to other valid TracePoint targets.

Finally, free the rb_hook_list_t struct when freeing the method
definition it lives on. Freeing in the GC is a good way to avoid
lifetime problems similar to the one fixed in df31715.

[Bug #18031]

`vm_trace_hook()` runs global hooks before running local hooks.
Previously, we read the local hook list before running the global hooks
which led to use-after-free when a global hook frees the local hook
list. A global hook can do this by disabling a local TracePoint, for
example.

Delay local hook list loading until after running the global hooks.

Issue discovered by Jeremy Evans in GH-5862.

[Bug #18730]

Check whether the current or previous frame is a Ruby frame in
call_trace_func and rb_tracearg_binding before attempting to
create a binding for the frame.

Fixes [Bug #18487]

Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>

This reverts commit 343ea9967e4a6b279eed6bd8e81ad0bdc747f254.

This causes an assertion failure with -DRUBY_DEBUG=1 -DRGENGC_CHECK_MODE=2

This is more backwards compatible, and should fix issues with
power_assert.

Unfortunately, it requires using a sentinel value as the default
value of target_thread, instead of the more natural expression
used in the original approach.

If TracePoint#enable is passed a block, it previously started
the trace on all threads.  This changes it to trace only the
current thread by default.  To limit the scope of the change,
the current thread is only used by default if target and
target_line are both nil.  You can pass target_thread: nil
to enable tracing on all threads, to get the previous
default behavior.

Fixes [Bug #16889]