Add st-flash flash target

[sigprof]

Description

Add support for flashing the firmware via the st-flash utility from the STLink Tools package (https://github.com/stlink-org/stlink).

The ST-LINK CLI utility used by the st-link-cli target is proprietary and Windows-only; the st-flash utility is open source (BSD 3-clause), and the STLink Tools package (called stlink, or sometimes stlink-tools) is available in many Linux distributions and in Homebrew for Mac OS.

I tested this with some STM32 development boards:

• STM32F103C8T6 “Bluepill” with the STM32duino user bootloader (the bootloader remains intact after flashing the handwired/onekey/bluepill firmware over ST-LINK)
• STM32F401CCU6 “Blackpill”
• STM32F411CEU6 “Blackpill”

The main reason for this PR is that some of the STM32F401CCU6 “Blackpill” boards sold on AliExpress apparently suffer from a combination of design deficiency and suboptimal component quality, and the builtin DFU bootloader on them is unreliable to the point of being unusable, so flashing them over ST-LINK seems to be much easier than trying to make the DFU bootloader start up properly by heating up the MCU. The problem is that the designer of those boards decided to use a 25 MHz crystal for HSE, and the builtin DFU bootloader attempts to determine the HSE frequency using the builtin HSI RC oscillator as a reference, which could actually work properly if the HSI frequency was within ±1% of 16 MHz, as written in the datasheet; however, apparently on some chips the factory calibration of HSI is much worse, and if the error is more than about 2% (for the 25 MHz crystal), the HSE frequency detection does not work properly, and then DFU gets lots of USB errors and does not work. Running the actual QMK firmware on those boards is not a problem, however, because the firmware uses a static PLL configuration for the 25 MHz crystal, and a wrong HSI frequency does not matter.

Other “Blackpill” board versions (STM32F411CEU6 and the updated STM32F401CEU6) could potentially have the same problem (they have the same 25 MHz HSE crystal).

I targeted the PR to develop, as requested in the new PR checklist, but the base of the branch is also suitable for master, if you decide that the change is trivial enough to be added there directly.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[tzarc]

For the record, I've also struck the annoying DFU problem with the F401's (maybe 1 in 8 successful boots to DFU), but the F411's I've got have all worked fine even with the 25MHz crystal.

[tzarc]

F103, F401, F411 all good.

[sigprof]

I found another place where the available flashing tools (somewhat confusingly named “bootloaders”) are listed — the qmk flash -b output, so I added st-flash there too (the -bl st-flash option worked even without that changes, only the help output was affected).

[noroadsleft]

Looks good to me.

[noroadsleft]

Thanks!