Fix STLink on MINDP initial halt delay

Detailed description

Not a feature.
The existing problem is BMDA + STLINK/V2-1 thinking it fails to cortexm_initial_halt() a MINDP stm32g071rb with an error message Halt via DHCSR(00030003): failure after 2028ms etc. which incurs said 2 seconds of delay during monitor swd_scan.
The PR solves this by gating the extra low_access when using STLINK_V2 backend type. Message becomes Halt via DHCSR(01030003): success after 2ms.

Inspecting PROBE loglevel traces indicates that, unlike BMPremote, stlinkv2 adapter firmware manages AP DRW + DP RDBUFF accesses behind the scenes, which are otherwise required for Cortex-M0/M0+ per specs. So the first read (from AP), which under plain line-level bitbangers returns garbage, here actually contains the data; and the second read (from DP) appears as zeroes. Ignore the "decreasing spam logline, it's not a part of this patch.*

stlink_raw_access: Attempting access to addr 010c via apsel 0
stlink_raw_access: addr 010c <- a05f0003
stlink_raw_access: Attempting access to addr 010c via apsel 0
stlink_raw_access: addr 010c -> 00030003
stlink_raw_access: Attempting access to addr 000c via apsel 65535
stlink_raw_access: addr 000c -> 00000000
cortexm_initial_halt: decreasing spam by sleeping for 100 ms
stlink_raw_access: Attempting access to addr 010c via apsel 0
stlink_raw_access: addr 010c <- a05f0003
stlink_raw_access: Attempting access to addr 010c via apsel 0
stlink_raw_access: addr 010c -> 00030003 # AP DRW returns the result early
stlink_raw_access: Attempting access to addr 000c via apsel 65535
stlink_raw_access: addr 000c -> 00000000 # DP RDBUFF was used
cortexm_initial_halt: decreasing spam by sleeping for 100 ms
stlink_mem_read from e000edf0 to 0x7ffe256a2944, len 4
Halt via DHCSR(00030003): failure after 2028ms
Try again with longer timeout or connect under reset
adiv5: Failed to prepare AP, results may be unpredictable

Your checklist for this pull request

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

Closing issues

Tested on Nucleo-G071RB with STLINK/V2-1 firmware versions V2J33M25, V2J45M30, and a WeActStudio BluePillPlus stm32f103cb running Blackmagic Debug Firmware v1.10.2 (+ BluePill+ PCB patches for PB2 LED and SPI1). The latter displays expected MINDP operation in BMPremote logs. Affected targets would be any MINDP debuggable with a stlinkv2, including ST parts with Cortex-M0 (F0 family) and Cortex-M0+ (l0, g0, c0, u0).

AP   0: IDR=04770031remote_v3_adiv5_ap_read: addr 01f4 -> 00000000
remote_v3_adiv5_ap_read: addr 0100 -> 03000052
remote_v3_adiv5_ap_read: addr 01f8 -> f0000003
 CFG=00000000 BASE=f0000000 CSW=e3000040 (AHB3-AP var3 rev0)
remote_v3_adiv5_dp_read: addr 0004 -> f0000040
remote_v3_adiv5_ap_write: addr 0100 <- e3000042
remote_v3_adiv5_raw_access: addr 0104 <- e000edf0 -> 00000000
remote_v3_adiv5_raw_access: addr 010c <- a05f0001 -> 00000000
remote_v3_adiv5_dp_read: addr 000c -> 00000000
remote_v3_adiv5_raw_access: addr 010c <- a05f0003 -> 00000000
remote_v3_adiv5_raw_access: addr 010c -> 00000000 # AP DRW returns nothing
remote_v3_adiv5_raw_access: addr 000c -> 01030003 # DP RDBUFF contains the result
Halt via DHCSR(01030003): success after 2ms

blackmagic-debug / blackmagic