Fix: Treat GD32E508 in JTAG transport as ADIv5

[ALTracer]

Detailed description

• No new features.
• The existing problem is GD32E508ZE device no longer accepted by BMD since introduction of Feature: ADIv6 JTAG support #1981 ADIv6 JTAG-DP support, v1.10.0-1445-g e010084 (bisected), because this chip is only ADIv5.
• The PR "solves" it by recognizing 0xba04 partno and setting DP version to 0 like older JTAG-DP, which used to work.

A temporary patch "like LPC43xx errata" may not be ideal, because this is not mentioned in GD32E5 errata, but likely ends up an actual Cortex-M33 DAP ("TEALDAP") that is SWJ-DP MINDP. But I leave DPv0/v1 and ADIv6 DPv3 distinction details to maintainers. It works with JLink and with OpenOCD, and it used to work with BMD, it's not new.
Note: the other in-tree CM33 chips, STM32H5, identify as 0xba00 which corresponds to CoreSight SoC-400 JTAG-DP, and ST is known to have used CoreSight SoC-400 IP in STM32H7/MP15 (SWO and TPIU at least). And RP2350 (ADIv6) relies on SW-DP.

Tested using BMDA v2.0.0-rc1 driving JLink V9, also driving blackpill-f411ce around v1.10.0-1200 (as remote v0 adapter without HL).

ID code 0x0ba04477: ADIv5 JTAG-DP port.
ID code 0x790007a3: Gigadevice BSD.
Unknown JTAG-DP found, please report partno code ba04
Not using ADIv5 acceleration commands
DP DPIDR 0x0be11477 (v1 MINDP rev0) designer 0x43b partno 0xbe

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

[dragonmux]

LGTM pending the fix we're working on writing to make the DP versioning behaviour correct in the low-level. Please rebase this on main and we'll get it merged.

Thank you for the contribution!