This PR changes the current JIT model from trace projection to trace recording. Benchmarks/stats TODO.

This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277

Some tests for the optimizers are disabled for now not because the optimizer doesn't work, but that it's actually unrolling recursion, thus leading to different results in the trace!

The full test suite passes on my system.

Not close enough to a holiday, so no poem this time!

Pros:

• Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
• optimizer.c is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
• The new JIT frontend is able to handle a lot more control-flow than the old one.
• Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. Specialization is still enabled while tracing.

Cons:

• (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though gh-139922: Tail calling for MSVC (VS 2026) #139962
• Build times for JIT is now a lot higher as we build two interpreters, not one. computed goto interpreter's build times is very long on my system. Tail call is roughly half the build times of computed goto as there's no blowup of CFG. I recommend building with tail call in the future if you want fast build times.

Design:

• We (ab)use the cases generator DSL to duplicate the normal interpreter --- one specializing interpreter, one tracing version.
• The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
• This was used instead of not duplicating the interpreter as it offers more powerful customization and specialization (see below).
• The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code.
• The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested. This is the power of having another interpreter.
• Because we do not share interpreters, there is no measurable slowdown to the original specializing interpreter. With JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
• Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- _DYNAMIC_EXIT. This new instruction will cause a re-trace when hot enough starting from the target instruction.
• As such, traces "grow" like a web/graph rather than a tree. It starts from a loop, then grows outwards naturally consuming more code around it as the hotspot gets hotter.
• I believe this might be the first time trace recording is combined with an inline caching + quickening interpreter (in literature by Brunthaler at least it's called that) to achieve specialization. Let's hope this goes well.

• Issue: Trace recording JIT #139109