Reorder USB endpoints for TraceSWO capture on STM32F4 platforms

[ALTracer]

Detailed description

• This is not exactly a new feature, but more of a support PR for something of bigger importance.
• The existing problem is Endpoint 5 IN used for all platforms, including STM32F4-based, for Trace Capture binary data. This works on STM32F1 FS Device with 8 endpoints, but doesn't work on DWC2 with 4 bi-dir endpoints including EP0 (0-3).
• This PR solves the problem by reordering important IN endpoints to stay under EP3 inclusive, but shifting CDC-ACM Notification Interrupt endpoints away to EP4 and EP5.

This is the first changeset in a series to enable TraceSWO (Async) Capture support on blackpill-f4 family of BMP-compatibles. I have tested the resulting combination on F411CE and observed ~480 KiB/s (of 6Mbaud) traffic in Orbuculum (despite /dev/ttyBmpTarg doing the same faster at 600 KiB/s) from STM32MP157C and GD32E508 targets with TDO pinned out, TPIU/SWO set up for UART at 6 Mbaud or other integer divided rates from 133.25 and 180 MHz respectively. This "adapter" itself can push about 1000 KiB/s of fixed payload traffic over a single VCP with a test firmware not using libopencm3. f4discovery would benefit this, too.

Next changes are #1529 and possible USART OVER8 in libopencm3 fork to allow in principle 12 Mbaud (96/8). USB FS may not sustain it, but 6.4, 8, 9.6 and 10 mega baudrates are nice to have, too. It may be beneficial to have independent TraceSWO Async and second CDC-ACM if the latter relays important info in real time, like physical TTL UART logs from DUT, or occasional RTT messages, or even semihosting redirected stdout (or BMP-originating diagnostic logging), all of which are potentially ASCII-printable. traceswodecode.c also prints there, when ITM_printf is sufficient, without binary traffic (like DWT events or TSDL instrumentation) -- but the problem of 5-to-1 mux of traffic is best solved elsewhere. OTOH, Async capture can be achieved by feeding TDO into AUX UART Rx and therefore sacrificing it -- Orbuculum supports serial ports (BMTrace might not). Manchester capture is not feedable into Aux uart Rx but requires two timer channels on a single input pin -- if ported from F1, it requires these changes.

I'll need to rebase the branch from November 2023 and drop backported changes, but feel free to review as I've submitted this.

Caveat 1: I expect problems from Windows 7 or MacOS or FreeBSD (or even Android?) during usage of both CDC-ACM ports of 4-EP F4 now, like DTR/RTS line state changes not getting back or ports hanging altogether (previously only second port was affected, first port worked properly), but I've been using Linux Mint (Ubuntu 22.04 LTS) with no problems in dmesg. F1 shouldn't break like this. Testing on other hosts is welcome. I only aim to empower Linux desktop-using developers, I don't have the resources to fight proprietary OS problems as well. No warranty or fittness for a particular purpose, as-is.

Caveat 2: Consumers of BMP Trace Capture need to be adjusted if they hardcode 0x85 (EP 5 IN), becomes 0x83 (EP 3 IN), namely scripts/swolisten.c, Orbuculum and Compuphase's BMTrace, really they all should walk USB descriptors using libusb. Interface is still 5, it's a logical number not physical pipe in USBOTG.

Caveat 3: Not sure whether driver/blackmagic.inf should need changes and signing, MS BOS already resolves some of that. Worst case users will need to uninstall drivers or clean registry entries if OS caches that, or you could bump .bcdDevice from 0x0109 or something.

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)
• [x] It builds as BMDA (see Building the BMDA) and does not affect it
• [ ] 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

Fixes #1671.

[ALTracer]

Amended last commit to keep O-packet contents compatible with any external RSP parsers. USB EP 0x 3 is too different from USB EP 5. I didn't go full USB EP 0x83 or revert all the way to serialno:0x05:0x83 for Interface 5 and Endpoint 3.

[dragonmux]

Sorry for it taking so long to get this all tested, etc - we're happy to say though that with this rebased on main, it all seems to work perfectly, so merging. Many thanks again!