Feature: implementation of jtagtap_cycle() for FTDI backend

[ALTracer]

Detailed description

• This is a minor new feature.
• The problem is BMD logic expects to use jtagtap_cycle() sometimes, but BMDA hasn't always provided it.
• This PR solves it by providing one moderately optimized implementation for FTDI MPSSE backend.

Tested on FT2232HL against a RISC-V MCU. Based on #2179. See #2180 for tracking other backends.
I would like some explanation, is buffering beneficial in the handlers, or does it exist externally (between two flush calls), then I can discard the 2nd commit.

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]

Please rebase this PR on main and we'll get it reviewed.

[dragonmux]

Couple of review notes, nothing too major though and with them addressed we'll be happy to merge this.

[ALTracer]

Your questions made me realize I've designed this with a logic bug, where it commands 0x8e 0xff when 8 clocks are requested; should be 0x8e 0x07 or 0x8f 0x00. Confirmed with a small throwaway unit test snippet.
upd: this might be as easy to fix as if (clock_bits >= 8) return;.

[ALTracer]

https://gist.github.com/ALTracer/3b3b1c67c39b2803044e218ec6d21261

[dragonmux]

LGTM, merging. Thank you for the contribution and this speed-up to the FTDI code for running cycles where TMS and TDI need to be kept constant