WIP: Feature: RV32I Progbuf-based memory access support, with autoexec #2225

Detailed description

• This is a new feature.
• The existing problem is that single-access version of progbuf-based memory I/O is very slow.
• This PR solves it by adding a linear read/write version based on abstractauto.data0 (assuming the chip supports it).

Based on #2185 and sequenced after it.
The limited testing indicates a 7 times speedup on an otherwise JTAG I/O-bound blackpill-f411ce against a JTAG RV32I* in compare-sections and 2 times speedup of (gdb) load against GD32VF103 flash.

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

The check for DM 0x18 abstractauto containing writable bits is now present as a separate first commit, which only touches riscv_debug.c/h. The next two commits have been manually rebased on whatever 2185 evolved into. Intermediate testing on blackpill-f411ce against GD32VF103 shows ~7.5x compare-sections read speed boost and ~2x (gdb) load flash programming boost (SRAM restore not tested) vs. single-progbuf. AAM might be preferable.

Problem 1. There is now partial setup outside the loop, and if any of the DM/CSR accesses fail, I have no good way of bailing out through restore (of saved GPR A0/A1). Just so it compiles (and so I don't simply return) I've inserted a do-while(false) idiom.
Problem 2. The current form is too simple, it always assumes that autoincrement is supported, and uses 2+1 slots. I need to properly guard and untangle autoexec path from single path.
Both problems could be solved if I extract the loops into their own small helper static functions, which then can return an error and still hit the GPR restore. However, I would not want to bloat BMF size greatly, current size-diff is +288.

Sidenote, Codeberg web interface still shows the old base PR2185 commits which is what I initially pushed to PR2225, even though I have already rebased and force-pushed twice (and it does not show these commits on PR Conversation page -- only on PR commits page). I don't like this, and it's different from Github.