Fix: ADIv5 debug bringup reliability

[dragonmux]

Detailed description

During the process of building target support for the Ambiq Apollo 3, Sid wound up hitting and issue where the debug reset code in the ADIv5 implementation would cause the target to quit talking SWD or JTAG till power cycled, preventing scan from working.

After working with zyp, mubes and Sid and reading the ADIv5 spec closely, we have come to the conclusion that we can get the effect of the reset sequence logic by instead powering down the debug engine on the target, then powering it back up. This is guaranteed by the spec for targets that actually implement power control on the APs and debug bus to cause the APs and debug bus to come back up via a reset, getting the same net effect as the prior logic.

This has been tested on a couple of different targets including the STM32F411, LPC4370 and Apollo 3, and appears to be reliable, with the AP bringup code mopping up the only potential stale values this can cause for targets that don't implement power control.

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 (make PROBE_HOST=native)
• It builds as BMDA (make PROBE_HOST=hosted)
• 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

[esden]

Another instance where I would love to have our HITL CI handy... it is impossible to know if it will work 100% on all targets the same way. But adhering to the "optimistic merging policy" let's merge it so that more people have a chance to test it before the next release.

[dragonmux]

Agreed, so far it's been fine across the targets we've tried, but our desk only has so many..