feat: add an interactive debugger to GnoVM

[mvertes]

We provide here an embedded interactive debugger to let the user control and inspect its program at symbolic level, with the same features and commands as classical debuggers: gdb, lldb or delve.

The debugger is enabled by setting the -debug flag in gno run command, which loads the target program and immediately shows a debugger prompt on the console:

$ gno run -debug /tmp/my-program.gno
Welcome to the Gnovm debugger. Type 'help' for list of commands.
dbg>

Providing -debug-addr flag allows to start a remote debugging session, and not interfer with the program stdin and stdout. For example, in a first terminal:

$ gno run -debug-addr :4000 /tmp/my-program.gno
Waiting for debugger client to connect at :4000

And in a second terminal, using a netcat like nc(1):

$ nc localhost 4000
Welcome to the Gnovm debugger. Type 'help' for list of commands.
dbg>

The debugger works by intercepting each execution step at virtual machine level (each iteration within Machine.Run loop) to a callback, which in turns can provide a debugger command REPL or check if the execution can proceed to the next step, etc.

The general logic and structure is there. It is possible to continue, stepi, detach, print, stack, etc and get a general feedback of the user experience and the impact on the code.

Efforts are made to make this feature minimally intrusive in the actual VM, and not interfering when the debugger is not used.

It is planned shortly after this PR is integrated to add the capacity to attach to an already running program, and to taylor the data format for existing debugging environments such as VScode, etc, as demand arises.

Resolves gnolang/hackerspace#54

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[mvertes]

I have found some issues when computing the stack from a non func block (like if or for body).

I also found some issues when printing a global var.

I would like also to set a test suite for the various debugger commands and in the various possible contexts such as the ones mentioned above. That requires a bit more work, maybe in a new PR (still pondering).

[harry-hov]

good to merge after fixing the path resolution and break command.

preapproving!

[zivkovicmilos]

It is always a joy to read your code 💯

I've left a few comments, mostly questions to help me better understand the direction.
Thank you for implementing this 🙏

[thehowl]

Approving, sorry this took long.

I have a few grievances about the code duplication. I'd really prefer if we didn't have multiple implementations of essentially the same functionality in the same VM; as I think these create a maintainability problem. I'd look, if possible, to proceed unifying the code for injectLocOnPanic / debugUpdateLocation; likewise for debugEvalExpr. (Also because, fun fact, we already do have a "minimalistic parser"; see go doc gnolang.X).

If you can undertake efforts of unification, I'd really appreciate it. It may seem like shallow work; but I really believe that in the long-run, it will help us to avoid having to fix issues in three different expression parsers.

Same for injectLocOnPanic. We will need to have good line reporting anyway, with #1981 (ie. having stacktraces on GnoVM panics), so it's probably best if we end up with a single, good implementation.

That said, thank you for undertaking the effort and taking the time to address review comments.

Merging.

[mvertes]

Yes @thehowl, I will now look at unifying common parts as you suggest. Thanks for your thorough review and useful suggestions.