[MEGA HAX] useful stack during template evaluation

[chancancode]

Instead of pulling the normal generator loop, this compiles each template block into a threaded function that drives the VM instead.

This essentially unrolls the core VM loop into normal imperative JavaScript code and function calls. This means we can use all the debugger functionalities (stepping, jumping between stack frames, watch expressions, etc) normally.

This uses indirect eval (new Function) and is intended for debug mode only.

Currently it passes all JIT tests for me locally but it breaks just about everything else. It also has lots of MEGA HAX, so it's really just a proof-of-concept at this point.

To try it, clone the branch, find a JIT test, introduce an error add a {{debugger}} statement somewhere in a template in the test, run the test with LOCAL_SHOULD_LOG, without try/catch, and with the debugger open.

I recommend the "correct scope - complex yield" test for this purpose as it has a good amount of nesting that show cases the usefulness of this feature well.

If you are lucky, maybe this URL will bring you there: http://localhost:4200/tests/index.html?enable_local_should_log&filter=jit&testId=2780f765

The easiest way to introduce an error is to invoke a component that doesn't exists. Once you have done it and refresh, you should be paused in the debugger (assuming you have pause on uncaught exceptions enabled) where the error is thrown. (Just use {{debugger}}, it's easier.)

You can go up the stack and see exactly the opcode execution sequence that got you here, with the nesting information. You can set a breakpoint anywhere in the opcodes before the error, refresh the page and be paused in the right location. You can even use conditional breakpoints, adding watch expressions for vm.pc, vm.stack.peek(), etc and have them update live as you step through the code.

[fivetanley]

@chancancode this is really exciting! is it possible to use the work in this PR to add the template location in here somehow? In https://github.com/glimmerjs/glimmer-vm/pull/972/files, @wycats mentions:

Next steps would include reporting the source location of unresolved
modifiers and components, as well as beefing up existing error cases to
go through the reporting infrastructure and have source locations.

Not super familiar with the architecture here, but wondering if adding more context for reporters , at least in development, might be unlocked by this work.