feat: automatically stop all motors when a breakpoint is triggered

[speedskater1610]

Summary

Adds a configurable feature that stops all connected Smart Motors (11W and 5,5W) when a breakpoint fires, before the GDB console loop even begins. This prevents a robot from driving away, and all motion in general.

Motivation

I want to learn the codebase, and I generally do that well by adding something to it.

API changed

// sets the default at construction time (persists) :
v5gdb::install(
    V5Debugger::new(StdioTransport)
        .with_motor_stop(true),
);

// Or leave it off (the default) and toggle it live from gdb :
// (gdb) monitor stop_motors on
// (gdb) monitor stop_motors off
// (gdb) monitor stop_motors                 # prints current state
// (gdb) monitor stop                        # one-shot manual stop, always available

Behaviour notes

• Default is false; meaning no change in behaviour for existing users.
• Live toggle - monitor stop_motors on/off takes effect on the very next breakpoint without having to restarting the program.
• Single step is unaffected - the auto-stop only fires on the initial breakpoint entry (show_debug_console path), not on each single step instruction. Calling stop_all_motors() on every single instruction would make stepping unusably slow and would clear motor state the user may be observing.

Testing

I tested on a physical brain didn't really see how testing with Qemu would help

[lewisfm]

The overall logic seems good, I just have a few code quality concerns to point out.

[speedskater1610]

Okay thanks because it is kinda late I will get to them tommarow.

[lewisfm]

A few small things mainly about the way you have docs set up, the core functionality looks good. Make sure to run rustfmt

[speedskater1610]

@lewisfm Sorry I got really caught up in some personal things but I will try to fix this by the end of the week since it has been a long time since I opened the pr.

[speedskater1610]

@lewisfm could you run CI then I can fix merge conflicts and should be ready to go.

[lewisfm]

@lewisfm could you run CI then I can fix merge conflicts and should be ready to go.

It won't let me run CI until merge conflicts are fixed (https://github.com/orgs/community/discussions/11265), you should just be able to run them yourself:

cargo clippy --target armv7a-vex-v5 --all-targets
cargo fmt --all --check

[speedskater1610]

I will get to it in the morning to tired for this right now

[speedskater1610]

@lewisfm Should be good to go now

[lewisfm]

Looks like the build is failing, I think the merge messed up the pr

[speedskater1610]

@lewisfm Okay everything builds and rustfmt works now.

[speedskater1610]

@lewisfm Everything SHOULD pass now I wasnt checking lint and rustfmt the same way ci is