Feature: change platform GPIO slew rate when high SWCLK frequency is requested

[ALTracer]

Detailed description

• This is a new feature.
• The existing problem is poor signal integrity (ringing/reflections, ground bounce) of stlinkv3 and blackpill-f4 platforms resulting in failure of initial scan on setups with poor ground connections.
• This PR solves it by runtime-matching STM32 GPIO OSPEED to the toggle rates indicated in datasheets.

Prior changes:
stlinkv3: #1945, v1.10.0-1289-g 27cbec7
blackpill-f4: #1717, v1.10.0-500-g b9969de; and #2044, v2.0.0-rc1-3-g a3bb02e

Because STLINK/V3E onboard Nucleo-H743ZI2 outright didn't work at highest reachable frequency (above 12 MHz) at 2 MHz slew rate, I gave 25 MHz a try and it worked. That platform is able to checksum target data at about 400 KiB/s.
MiniSTM32F4x1Cx is slower, but still can hit 8.72 MHz (96/11) without significant firmware changes, and this is uncomfortably outside DS10314 ranges (C_L = 10 pF, Vdd > 2.7, F_max(IO)out = 8 MHz).
But to reduce noise at lower frequencies, I suggest a platform callback which reverts to OSPEED_2MHz when crossing some frequency boundary. There are no series resistors, no buffers, and we can't expect users to always use two good ground wires, especially when other adapters work fine with just one. Shields and carriers can help this.
I don't think STM32F1-based platforms are affected, because a) fastest SWCLK primitives (no_delay) only reach 3.6-4.0 MHz, b) datasheet indicates 2 and 10 MHz f_max(IO)out for C_L = 50 pF.

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) and should not affect it
• 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

[birkenfeld]

Works for me, however I have to set SWD frequency to 2 MHz to get the low speed because the default is 3 MHz.

Could you either change the default to 2 MHz or change the cutoff to 3 MHz? People who want really high speed will have to set the frequency anyway, while people like me who expect things to "just work" will be initially just as surprised with the cutoff in this patch.

Thanks!

[dragonmux]

We've got only the one comment, but otherwise this LGTM so as this has been shown to work on a couple of people's adaptors, we'll get this merged. Thank you for the contribution!

[dragonmux]

Ideally this wouldn't be here.. but we recognise that this is the cleanest way to have the function just implemented for all platforms while still being overridable, so we'll allow it.

[dragonmux]

We'll add that: despite your self-classification as a feature, because of what this changes and that it fixes a reliability issue, we are treating this as a fix for a bug.