perf(vm): new tailcalling dispatch behind feature tailcall (nightly required)

[zhuzhu81998]

Closes #4858 .
I had to move the big opcode list around a bit hence the large number of diffs.
Specifically, had to split the opcode handlers generation into a separate macros so feature-conditional compilation works. And to avoid repeating the gigantic opcode list twice (for tailcall and non-tailcall handlers), i put the list into a helper macros for_each_opcode.

Budgeted handlers would still use the standard loop-based approach.
Tailcalling handlers support tracing as well.

On main:

PROGRESS Richards
RESULT Richards 407
PROGRESS DeltaBlue
RESULT DeltaBlue 359
PROGRESS Encrypt
PROGRESS Decrypt
RESULT Crypto 350
PROGRESS RayTrace
RESULT RayTrace 623
PROGRESS Earley
PROGRESS Boyer
RESULT EarleyBoyer 785
PROGRESS RegExp
RESULT RegExp 104
PROGRESS Splay
RESULT Splay 1376
PROGRESS NavierStokes
RESULT NavierStokes 849
SCORE 484

With this PR and tracing enabled (cargo run --release --bin boa --features tailcall -- ../data/bench/bench-v8/combined.js):

PROGRESS Richards
RESULT Richards 459
PROGRESS DeltaBlue
RESULT DeltaBlue 390
PROGRESS Encrypt
PROGRESS Decrypt
RESULT Crypto 377
PROGRESS RayTrace
RESULT RayTrace 669
PROGRESS Earley
PROGRESS Boyer
RESULT EarleyBoyer 844
PROGRESS RegExp
RESULT RegExp 104
PROGRESS Splay
RESULT Splay 1479
PROGRESS NavierStokes
RESULT NavierStokes 971
SCORE 524

TODO:
- [ ] budgeted dispatch still use old call threading right now. (async interrupt does not play very well with tailcalling dispatch)

• tracing is not exactly integrated right now

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	52,963	52,963	0
Passed	50,073	50,073	0
Ignored	2,072	2,072	0
Failed	818	818	0
Panics	0	0	0
Conformance	94.54%	94.54%	0.00%

Tested main commit: 0698e7063866a1b40be043a1089be43d3224db4b
Tested PR commit: 4de933b61e8a70722a6fa8d51c712e9630220fef
Compare commits: 0698e70...4de933b

[codecov]

Codecov Report

❌ Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.21%. Comparing base (6ddc2b4) to head (4de933b).
⚠️ Report is 875 commits behind head on main.

Files with missing lines	Patch %	Lines
core/engine/src/vm/mod.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #5047       +/-   ##
===========================================
+ Coverage   47.24%   59.21%   +11.96%     
===========================================
  Files         476      563       +87     
  Lines       46892    62797    +15905     
===========================================
+ Hits        22154    37185    +15031     
- Misses      24738    25612      +874     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zhuzhu81998]

So there was a noticeable performance drop when i added the tracing part to dispatch_next in 2bab9b7 . The v8_bench score dropped from 550 to 520, even though tracing was not enabled so the path was not actually taken. And the performance is bit too big to be explained by a condition check, especially since it should be easily predictable by the cpu.

I think it might be related to how preserve_none works, but my experimental approach of splitting the traced path into a separate function did not really help.

It is also possible that maybe my 550 benchmark was an outlier 😂 . Will investigate a bit more.