initial attempt at time travel debugging

[mreinstein]

This PR isn't meant to be merged (hence the draft state), mostly showing the v1 prototype and soliciting feedback.

Puts the new debugger in another hyperscript plugin, ttd.js so as not to interfere with the existing hdb module (for now)

• add some core hyperscript event types emitted by the runtime,hyperscript:beforeEval, hyperscript:afterEval so the debugger can record context state before and after each node runs
• registers a DOM mutation observer to record changes to the dom so html state can be replayed along with hyperscript state
• stores "execution streams" which provide ids marking asynchronous runs
• console UI only for now, intentionally. type ttd.help() to see the various properties and methods available
• 2 e2e tests available, open ttd-test-workers.html?_ttd=true and ttd-test.html?_ttd=true in a browser as starting points

known issues:

• enables re-winding by shallow cloning the runtime context prior to evaluating nodes. Without deep copies some types of rewinding-editing-forward won't function correctly
• the dom mutations enables some html state handling, but not everything can be restored this way. For example the contents of iframes, some form input, dialog state, etc. don't show up as mutation events so they aren't tracked
• there's no execution stack stored yet
• there's no run time code/ast re-parsing yet

[1cg]

Heya Mike, thank you for this!

Some feedback:

• the core looks good to me!
• I'm a little worried about events before/after every statement execution for perf reasons esp when people aren't using the debugger, would a callback/null check be acceptable here?
• There are a few changes that look maybe unrelated? (biome.js, worker.js?)

[1cg]

I'm going to propose renaming this to debugger.js and planning on removeing hdb in favor of it. Do you want me to create a branch for this work? I can start working on the UI.

[planted-mreinstein]

worried about events before/after every statement execution for perf reasons

I don't have a strong opinion in favor of the event emitting method, cool with the callback approach. If you have any suggestions on naming, attributes etc. that conform to existing norms, happy to use those.

There are a few changes that look maybe unrelated? (biome.js, worker.js?)

Yes - on biome.js it's something I committed so that my editor doesn't try to lint/re-format the entire codebase and worker.js, I was having trouble on my dev branch getting workers to behave. I assume it may have been resolved since the dev branch was volatile around the time I forked.

propose renaming this to debugger.js and planning on removing hdb in favor of it

This PR intentionally was never meant to be merged as-is, which is why I added ttd.js and committed those extra files. Do we want to first attempt a more ambitious prototype v2, with code editing and more robust value editing before attempting to package this as the new ordained debugging interface?