Before this change, GC'ing any Ractor object caused you to lose all
enabled tracepoints across all ractors (even main). Now tracepoints are
ractor-local and this doesn't happen. Internal events are still global.

Fixes [Bug #19112]

https://github.com/ruby/ruby/actions/runs/17413734881/job/49436975287

Always use opt_new behavior regardless of tracepoint state.

This commit inlines instructions for Class#new.  To make this work, we
added a new YARV instructions, `opt_new`.  `opt_new` checks whether or
not the `new` method is the default allocator method.  If it is, it
allocates the object, and pushes the instance on the stack.  If not, the
instruction jumps to the "slow path" method call instructions.

Old instructions:

```
> ruby --dump=insns -e'Object.new'
== disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)>
0000 opt_getconstant_path                   <ic:0 Object>             (   1)[Li]
0002 opt_send_without_block                 <calldata!mid:new, argc:0, ARGS_SIMPLE>
0004 leave
```

New instructions:

```
> ./miniruby --dump=insns -e'Object.new'
== disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)>
0000 opt_getconstant_path                   <ic:0 Object>             (   1)[Li]
0002 putnil
0003 swap
0004 opt_new                                <calldata!mid:new, argc:0, ARGS_SIMPLE>, 11
0007 opt_send_without_block                 <calldata!mid:initialize, argc:0, FCALL|ARGS_SIMPLE>
0009 jump                                   14
0011 opt_send_without_block                 <calldata!mid:new, argc:0, ARGS_SIMPLE>
0013 swap
0014 pop
0015 leave
```

This commit speeds up basic object allocation (`Foo.new`) by 60%, but
classes that take keyword parameters see an even bigger benefit because
no hash is allocated when instantiating the object (3x to 6x faster).

Here is an example that uses `Hash.new(capacity: 0)`:

```
> hyperfine "ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end'" "./ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end'"
Benchmark 1: ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end'
  Time (mean ± σ):      1.082 s ±  0.004 s    [User: 1.074 s, System: 0.008 s]
  Range (min … max):    1.076 s …  1.088 s    10 runs

Benchmark 2: ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end'
  Time (mean ± σ):     627.9 ms ±   3.5 ms    [User: 622.7 ms, System: 4.8 ms]
  Range (min … max):   622.7 ms … 633.2 ms    10 runs

Summary
  ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end' ran
    1.72 ± 0.01 times faster than ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end'
```

This commit changes the backtrace for `initialize`:

```
aaron@tc ~/g/ruby (inline-new)> cat test.rb
class Foo
  def initialize
    puts caller
  end
end

def hello
  Foo.new
end

hello
aaron@tc ~/g/ruby (inline-new)> ruby -v test.rb
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24]
test.rb:8:in 'Class#new'
test.rb:8:in 'Object#hello'
test.rb:11:in '<main>'
aaron@tc ~/g/ruby (inline-new)> ./miniruby -v test.rb
ruby 3.5.0dev (2025-03-28T23:59:40Z inline-new c4157884e4) +PRISM [arm64-darwin24]
test.rb:8:in 'Object#hello'
test.rb:11:in '<main>'
```

It also increases memory usage for calls to `new` by 122 bytes:

```
aaron@tc ~/g/ruby (inline-new)> cat test.rb
require "objspace"

class Foo
  def initialize
    puts caller
  end
end

def hello
  Foo.new
end

puts ObjectSpace.memsize_of(RubyVM::InstructionSequence.of(method(:hello)))
aaron@tc ~/g/ruby (inline-new)> make runruby
RUBY_ON_BUG='gdb -x ./.gdbinit -p' ./miniruby -I./lib -I. -I.ext/common  ./tool/runruby.rb --extout=.ext  -- --disable-gems  ./test.rb
656
aaron@tc ~/g/ruby (inline-new)> ruby -v test.rb
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24]
544
```

Thanks to @ko1 for coming up with this idea!

Co-Authored-By: John Hawthorn <john@hawthorn.email>

Originally, if a class was defined with the class keyword, the cref had a
const_added callback, and the superclass an inherited callback, const_added was
called first, and inherited second.

This was discussed in

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

and an attempt at changing this order was made.

While both constant assignment and inheritance have happened before these
callbacks are invoked, it was deemed nice to have the same order as in

    C = Class.new

This was mostly for alignment: In that last use case things happen at different
times and therefore the order of execution is kind of obvious, whereas when the
class keyword is involved, the order is opaque to the user and it is up to the
interpreter.

However, soon in

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

Matz decided to play safe and keep the existing order.

This reverts commits:

    de097fbe5f3df105bd2a26e72db06b0f5139bc1a
    de48e47ddf78aba02fd9623bc7ce685540a10743

[Misc #21143]

Conceptually this makes sense and is more consistent with using
the `Name = Class.new(Superclass)` alternative method.

However the new class is still named before `inherited` is called.

TestSetTraceFunc#test_tracepoint_disable is a flaky and failing intermittently. Here is an example of failure logs.

```
   1) Failure:
  TestSetTraceFunc#test_tracepoint_disable [/home/runner/work/ruby/ruby/src/test/ruby/test_settracefunc.rb:857]:
  <[:foo, :disable, :foo, :disable]> expected but was
  <[:call, :call, :foo, :disable, :foo, :disable]>.
```
https://github.com/ruby/ruby/actions/runs/13619175633/job/38066208546?pr=12585#step:12:875

I printed values of TracePoint objects as follows, and checked the values when failing intermittently.

https://github.com/ruby/ruby/blob/7f9a6fc582fb5cfd88ab73a61782f39894a37ba6/test/ruby/test_settracefunc.rb#L848

Here is the log when the TestSetTraceFunc#test_tracepoint_disable failed intermittently.

`2025-03-05T09:08:37.4075411Z e: call, f: /home/runner/work/ruby/ruby/src/lib/tempfile.rb, l: 386, i: call, d: Tempfile::FinalizerManager` is an unexpected events. Thus, I modified test code so that we can filter out unexpected trace events.

```
2025-03-05T09:08:37.4075411Z e: call, f: /home/runner/work/ruby/ruby/src/lib/tempfile.rb, l: 386, i: call, d: Tempfile::FinalizerManager
2025-03-05T09:08:37.4085009Z e: call, f: /home/runner/work/ruby/ruby/src/test/ruby/test_settracefunc.rb, l: 808, i: foo, d: TestSetTraceFunc
2025-03-05T09:08:37.4086042Z e: call, f: <internal:trace_point>, l: 295, i: disable, d: TracePoint
2025-03-05T09:08:37.4115693Z e: call, f: /home/runner/work/ruby/ruby/src/test/ruby/test_settracefunc.rb, l: 808, i: foo, d: TestSetTraceFunc
2025-03-05T09:08:37.4116734Z e: call, f: <internal:trace_point>, l: 295, i: disable, d: TracePoint
```

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`.