Feature: implementation of jtagtap_cycle for JLink backend

[ALTracer]

Detailed description

• This is a minor new feature.
• The problem is rudimentary/poor implementation of jtagtap_cycle() in jlink.c backend used by BMDA. (and it didn't even exist until very recently)
• This PR solves it by providing one moderately optimized variant.

Tracking: #2180.
Note that jlink_jtag_init() used to rely on a direct jlink_transfer() of a baked byte buffer with 56 idle clocks and SWD-to-JTAG switch sequence, I replaced that with a jlink_jtag_cycle() call for 56-5=51 clocks and a shorter, 16-bit sequence. The caveat is that new function may raise an exception, and at scan time it results in immediate SIGABRT because it's unhandled (by any TRY-CATCH up the callsite). It also happens to be the first 0xCF opcode transfer. If such behaviour is unwanted, discard commit 1.

Tested on J-Link V9 against a RISC-V MCU.

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]

Couple of things we notice reviewing this, but with them fixed we'll be happy to merge this.

[dragonmux]

The suggested other way to express the cycle logic we think fits quite well - doesn't need byte ordering shenanigans, or wide shift and subtract - with the first block of the #if/#else removed and the two small notes below addressed, we'll be happy to merge this.

[dragonmux]

LGTM, merging. Thank you for the contribution and this improvement to the J-Link backend!