Fix: Missing RISC-V debug guard

[dragonmux]

Detailed description

This PR addresses an oversight of #1683 resulting in a build error when ENABLE_DEBUG is not true.

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

[ALTracer]

Explanation:

• Hosted and release firmware builds work (and are checked by CI anyways).
• I checked with a script that all ENABLE_DEBUG=1 devlog firmware variants build as of main v1.10.0-226-g529c4a46 (where flash size allows).
• Requesting a release firmware with riscv target driver feature via ENABLE_RISCV=1 throws a single warning on

target/riscv32.c: In function 'riscv32_mem_write':
target/riscv32.c:580:30: error: unused variable 'data' [-Werror=unused-variable]
  580 |         const uint8_t *const data = (const uint8_t *)src;
      |                              ^~~~

which this PR fixes by gating the code block with mentioned variable and DEBUG_PROTO on #ifdef ENABLE_DEBUG.

• Requesting a devlog firmware with riscv target driver feature via ENABLE_DEBUG=1 ENABLE_RISCV=1 throws both warnings:

target/riscv32.c: In function 'riscv32_mem_read':
target/riscv32.c:565:30: error: unused variable 'data' [-Werror=unused-variable]
  565 |         const uint8_t *const data = (const uint8_t *)dest;
      |                              ^~~~
target/riscv32.c: In function 'riscv32_mem_write':
target/riscv32.c:580:30: error: unused variable 'data' [-Werror=unused-variable]
  580 |         const uint8_t *const data = (const uint8_t *)src;
      |                              ^~~~

because DEBUG_PROTO is a no-op on adapters. This no longer allows emitting up to DEBUG_INFO verbosity messages from adapters for diagnosing issues specific to BMF and not BMDA.

Putting a #if PC_HOSTED == 1 guard in these two makes the builds succeed.

Note that all prior use of DEBUG_PROTO was contained in src/platforms/hosted/platform.c and not exposed to BMF/adapters. ADIv5 read/write proto logs AFAICS are handled purely in hosted -- this looks very much like adiv5_mem_read(), and I wonder if target_mem_read() should wrap this instead. There are inline wrappers in adiv5.h which omit the DEBUG_PROTO logging for BMF.

[dragonmux]

Yes, guarding on PC_HOSTED would make things build for in-tree platforms, but is not really the right fix.

What we're going to do now we understand the nature of those second two build failures is to create new macros that define if their respective DEBUG_* macro is defined to be a no-op or not, and guard the assignments using those. (It was not made clear on Discord that you meant you'd done a firmware build with those two enables, so we didn't twig that the guard this provides is insufficient due to how DEBUG_PROTO() is defined for the firmware.)

[dragonmux]

That case should now be handled with the new DEBUG_*_IS_NOOP macros and further guarding the conversion/assignment lines

[esden]

LGTM