[enhancement] Add debugger support to DSLX interpreter

### What's hard to do? (limit 100 words)

Understanding how DSLX code behaves during execution is difficult without the ability to step through code or observe variable values. The DSLX interpreter doesn’t support features available in debuggers like breakpoints, stepping, or inspecting data as the program runs. This makes it harder to follow control flow or spot incorrect behavior, especially in larger or more complex designs. More visibility during execution would help with debugging and validating logic more efficiently.

### Current best alternative workaround (limit 100 words)

One approach s to use `trace_fmt!` to print intermediate values during the program operation. This is helpful but requires inserting traces manually and rerunning the code. Targeted tests can also help isolate bugs, and reviewing the IR or Verilog simulation may give further insight. It's also possible to analyze channel activity using the `--trace_channel` flag, but these methods are limited and not interactive.

### Your view of the "best case XLS enhancement" (limit 100 words)

A useful enhancement would be adding debugger support to the DSLX interpreter, following the [Debug Adapter Protocol (DAP)](https://microsoft.github.io/debug-adapter-protocol/). This would allow integration with popular editors like VSCode, (Neo)vim, or Emacs and enable breakpoints, step-by-step execution, and variable inspection. Even a minimal implementation would make understanding and verifying designs easier, especially when debugging procs and testbenches. While the interpreter is sequential and doesn’t reflect actual hardware parallelism, it can still be valuable for validating functional correctness and reasoning about DSLX logic.