Feature: re-enable non-halting RTT on a few targets

[ALTracer]

Detailed description

• This is not a new feature, this restores BMD behaviour before Fix: Memory access halting heuristic #1962.
• The existing problem is BMP with RTT halts all its targets by default to check controlblock contents in SRAM. This is incompatible with any real-time firmware, we get packet loss and CRC errors.
• The PR solves it by enabling the provisioned target flag on targets where I've tested RTT to return non-garbage data even if the processor keeps running.

Testcases are Arduino/stm32duino RTT_Stream speedtest.ino sketch and Eclipse uOS++ ilie with Segger's RTT sources from their examples zip. Unfortunately I haven't been able to find an independent opensource implementation of RTT to include in libopencm3-based firmware testcases, and I don't want to dip in Rust for this.
Confirmed to increase RTT data read speed on Nucleo-G071RB and GD32E508ZE, to stop dropping Rx SPI words on WeAct Studio AT32F403ACG.
Pending testing on STM32F103CB, GD32F103CB, GD32F303CC (all WeAct Studio BluePill-Plus boards).
BMP platform used is mostly blackpill-f411ce but stlink/swlink is also possible. BMDA is likewise affected.

Note I cannot test GD32F2 and GD32E230, where it is unknown to work. Especially so I cannot test on TM4C123 which is the one and only reported problematic Cortex-M4F core.

A good metric of detecting DUT halts without parsing SWD traffic or BMP advanced logging or running any realtime communication protocols (or wiggling GPIOs) is running a peripheral TIMer in Output PWM mode at 100% duty cycle with DBGMCU APB freeze bit set for it -- as soon as Processing Element gets halted, TIM_OCx goes low (confirmed on oscilloscope watching SWD), and goes back high on resuming, and there's no extra spurious transitions.

First commit (which touches target/cortexm.c) is obviously not intended to land on main as part of this PR, it is only provided for convenience of A/B-testing without reflashing BMPs (there's a runtime switch for monitor mem_nohalt enable)

If wildcard-enabling this behaviour on entire families not flavours is acceptable, then I can move the flag-setting code out of branches and simplify firmware further.

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

[beefdeadbeef]

FWIW i've tested this on AT32F42x (namely at32f425f8p7) and AT32F437 found on at-start-f437 eval board.
works for me.

[markrages]

Please also add non-halting for nRF54L target.

[markrages]

Thank you

[Copper280z]

Tested non-halting access on an STM32H723 nucleo using BMDA+stlink and got good data via RTT.