Store active runnable and active function in CallFrame

[HalidOdat]

Depends on #3185

Part of refactoring calling in VM. In this PR active runnable and active function are moved in the CallFrame, this allows us to untangle some of the function calling.

It may seem like we are using more memory per ordinary function call, because of CallFrame size increase, but it actuality it's the same, before instead of storing it in the call frame we would spill it on the native rust stack which was filling the stack, contributing to smaller recursion limits.

@nekevss As I see it we already have the execution context stack, that being the CallFrames (just a different name), we just have some work moving some fields that are supposed to be in an execution context like [[ScriptOrModule]] which this PR does, realm needs to be moved too.

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	95,410	95,410	0
Passed	75,078	75,078	0
Ignored	19,342	19,342	0
Failed	990	990	0
Panics	0	0	0
Conformance	78.69%	78.69%	0.00%

[codecov]

Codecov Report

Patch coverage: 66.33% and project coverage change: +0.01% 🎉

Comparison is base (3c15e59) 50.30% compared to head (1c804fc) 50.31%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3197      +/-   ##
==========================================
+ Coverage   50.30%   50.31%   +0.01%     
==========================================
  Files         436      436              
  Lines       42656    42608      -48     
==========================================
- Hits        21456    21440      -16     
+ Misses      21200    21168      -32     

Files Changed	Coverage Δ
boa_engine/src/builtins/async_function/mod.rs	39.13% <0.00%> (ø)
...ngine/src/builtins/async_generator_function/mod.rs	46.15% <0.00%> (ø)
boa_engine/src/builtins/error/aggregate.rs	22.22% <0.00%> (+0.94%)	⬆️
boa_engine/src/builtins/error/eval.rs	72.72% <0.00%> (+4.15%)	⬆️
boa_engine/src/builtins/error/range.rs	72.72% <0.00%> (+4.15%)	⬆️
boa_engine/src/builtins/error/reference.rs	73.52% <0.00%> (+4.08%)	⬆️
boa_engine/src/builtins/error/syntax.rs	73.52% <0.00%> (+4.08%)	⬆️
boa_engine/src/builtins/error/type.rs	83.01% <0.00%> (+3.01%)	⬆️
boa_engine/src/builtins/error/uri.rs	72.72% <0.00%> (+4.15%)	⬆️
boa_engine/src/builtins/function/mod.rs	39.19% <ø> (-0.35%)	⬇️
... and 20 more

... and 2 files with indirect coverage changes

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

[nekevss]

I still have to take a look at the PR in a bit more detail, but I thought I'd bring it up just a small discussion point early, especially since it may have been obvious that it was coming 😆

Using CallFrame as an the execution stack could definitely work. It would potentially simplify things as storing everything in a singular place, but would there be any value in adding an execution_stack on the vm that takes a record (e.g. Vec<ExecutionContext>) more aligned with the spec. This would mean also not using swap on calls I think. Again, that could be the wrong approach, but thought I'd bring it up nonetheless.

[HalidOdat]

Using CallFrame as an the execution stack could definitely work. It would potentially simplify things as storing everything in a singular place, but would there be any value in adding an execution_stack on the vm that takes a record (e.g. Vec<ExecutionContext>) more aligned with the spec. This would mean also not using swap on calls I think.

In my opinion, I don't see any advantages in doing this, We already have Vec<CallFrame> the only difference is the name, which we can change.

[nekevss]

A lot of this looks pretty good to me. Just one small thing I noticed 😄

[nekevss]

Looks good to me 😄