Add debugging support

[Crushless]

Is your feature request related to a problem? Please describe. I want to embed WAZERO as a multi langue runtime in a Go host program (it's some sort of a domain specific IDE). The Go host program has an UI to write scripts (in any language that can be compiled to WASM), execute them, and also let the user to debug the code. My Go host program will call the WASM compiler for the source language and make sure, that the source code is being recompiled with DWARF information when the user decides to start debugging. So I need a way to register break points on lines / instructions of the WASM source code in WAZERO, then step through them line by line / instruction by instruction and providing a call stack and scope information. Because speed is not important while debugging, adding this feature to the interpreter only should be enough. DWARF should have have enough information to allow WAZERO to implement such a feature, because newer Chrome versions support WASM debugging and provide the basic features I described above (https://developer.chrome.com/blog/wasm-debugging-2020).

Describe the solution you'd like A method to register breakpoints and provide a callback function in the WAZERO interpreter. Just before the line / instruction is being executed, the interpreter calls the callback function. The callback function should have a parameter with the full internal state of the interpreter (like stack trace, variables, etc...). Variables and stack trace should be demangled by DWARF information. There should also be methods to instruct the interpreter to continue execution (and only call the callback function if another break point is being hit), execute the current instruction (and on the next instruction call the callback function), or if the instruction is a method call, call the callback method on the first instruction in the called method. Just basic features for a debugger.

Describe alternatives you've considered I considered using GDB and running my WASM binary as a separate process, but this is very cumbersome and controlling GDB remotely is a nightmare. WAZERO is already perfectly integrated in my Go host program and runs the scripts just fine. Only the debugging feature is missing.

[ncruces]

ISTM this feature makes sense, especially as interpreter only, but I'm not sure the team is able to dedicate time to implement it.

[achille-roussel]

@Crushless if you have the cycles to submit a pull request implementing the feature, it's likely that we can find time to review and merge the work.

I agree with @ncruces that doing this in interpreter mode only would be preferred, at least as an initial step.

I would also recommend that any newly exported APIs you need be added into the experimental package, maybe even in a new sub-package of it, so we can incrementally explore the new feature, and only commit to backward compatibility when we have more experience with the solution.

Let us know!