New platform: WeActStudio.BluePill-Plus-GD32

[ALTracer]

Detailed description

• This is a whole new cleaned up platform.
• The existing problems are mismatching LED pins and incomplete mappings of board features between stlink/swlink and bluepillplus. In-tree platforms default to 72 MHz and do not leverage full potential of Gigadevices. Unmapping own SWJ-DP is not always acceptable, and stlink pinout is just weird.
• This PR solves that by providing all necessary bindings in a dedicated platform, with chip detection and PLL configuration.

I do not expect this to be merged, because in-tree -Dprobe=bluepill already does provide some functionality. I do not implement vanilla PC13 bluepills, it's impossible for me to discern these from bluepillplus. This platform has feature parity with blackpill-f4, except I'm dissatisfied with its USBOTG-FS DWC2 bugs.
Choice of USART for Aux and SWO was influenced by existing 2x128 aux_serial DMA ping-pong buffers, which are insufficient for 1024 byte Zmodem packet operation I need in DUT firmware. So SWO is faster for burst operation. When that's refactored, I'll swap them back such that 6Mbaud VCP is possible.

TODO: I'd like to use platform_ident to indicate autodetection results, and to leverage meson options to pick linkerscripts which influence flash size for drivers and RAM size for heap/buffers/SWO.

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

[ALTracer]

This now supports 96 MHz APM32F103CB.
As well as classic 72MHz STM32F103CB, 96MHz GD32F103CB and 120MHz GD32F303CC (Cortex-M4), differentiating on CoreSight ROM table PIDR value. Unique ID in DESig is not exactly helpful, but serialno.c still works.
All four WeActStudio.BluePill-Plus-* boards have identical PCB, with LED on PB2 active-high, and button on PA0, USB FS device on type-C port, and 8 MHz crystal. All four chips lack USB DFU bootloader capability, only USART1 is supported for initial flashing, if you don't have another USB-SWD/JTAG adapter.
CH32F103C8 not considered due to insufficient Flash capacity.