Clear RISC-V hart triggers during attach/detach

[ALTracer]

Detailed description

• This is not a new feature.
• The existing problem is RISC-V triggers (breakpoints/watchpoints) can get stuck in the target if BMP suddenly disappears (JTAG disconnected, or USB/firmware reset, or BMDA terminated).
• The PR solves that by resetting tdata1/tdata2 to zero in riscv_attach() & riscv_detach().

Normally GDB is supposed to set-unset all break/watch points (Z/z-packets) on every halt/resume, and remove them before detach. However, for unrelated reasons, when I used blackpill-f411ce against GD32VF103CB, sometimes it got stuck busy-looping during ordinary step/next/finish commands (automatically using hardware breakpoints). Then I Ctrl+C out twice from GDB to disconnect, do a usbreset 003/012 against "BMP", tio notifies me it Disconnected/Connected to ttyBmpTarg, and again I start GDB, scan, attach, continue debugging -- here GDB/BMP don't know that some of 4 triggers are in use, will report SIGTRAP when these hit, but won't let me easily remove them. One workaround is to enqueue 4 different breakpoints and resume+halt once; another is to power-cycle the target (which is not applicable to every board, consider battery-powered devices).
This is also reproducible with BMDA. Additionally, if you try to step/continue across any watchpoint that hits, GDB+BMD busyloop each other with "breakpoint hit" (actually watchpoint) -- "vCont" with no way out. I suppose this is a separate issue, but clearing out triggers helps to back out of it.

Cortex-M layer clears out FPB and DWT comparators during attach/detach, Cortex-A/R layer clears out DBG_WCR/WVR (watchpoint control/value) of Debug Unit during attach/detach, too. I'm not sure why, and I also have opinions about DWT being possibly used by firmware for realtime trace. But let's bring RISC-V layer to feature parity with them.

Question for testing. What happens on targets which implement 0 trigger slots? WARL semantics allow both loops to execute once with no side effects? There is another issue where BMD reports 1 trigger discovered (0++ equals 1) even if it's not implemented.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues