LibJS: Investiagte relationship and responsibilities of JS `ExecutionContext` and Bytecode `CallFrame`

Both seem to fulfill similar purposes on different levels of abstraction of our JS virtual machine; The execution context is spec mandated, but also holds some extra information not mandated by the spec, some of which maybe possibly moved into the bytecode CallFrame/Register file without any impact of meaning:

• this value: We already have a register for this, which is populated by vm.resolve_this_binding And we have a this_value which seems to be largely unused, and is populated on startup and native function calls and seems to be only used for async blocks and GC

• local variables (#21447) These are, as seen in the linked PR, easily movable into the register file With the note that due to the way bytecode execution works and a register file becomes active, we need to pass the correct, not yet active, register file around, while the correct execution context was already active and easily accessible, this seems to negatively impact performance to resolve this we should/could:

  • revamp the way we start bytecode execution to allow an earlier binding of CallFrames
  • inline some (indirect) users of execute_ast_node during bytecode generation

  Note that in that PR the ExecutionContext still knows how many local variables it owns, this could theoretically be moved to the CallFrame or retrieved form the [[Function]] field in the ExecutionContext