arch/rp23xx: Fix six register/bit macro name clashes

[casaroli]

Summary

The rp23xx hardware headers define a register address macro for every register,
then a block of register bit definitions. In three headers a bit definition
reuses the name of a register address macro, so that register address is
silently redefined as a bit mask:

Macro	Intended (register address)	Redefined to
RP23XX_POWMAN_BADPASSWD	0x40100000	(1 << 0)
RP23XX_POWMAN_BOD_CTRL	0x40100018	(1 << 12)
RP23XX_POWMAN_DBG_PWRCFG	0x401000a4	(1 << 0)
RP23XX_BUSCTRL_BUS_PRIORITY_ACK	0x40068004	(1 << 0)
RP23XX_BUSCTRL_PERFCTR_EN	0x40068008	(1 << 0)
RP23XX_PADS_QSPI_VOLTAGE_SELECT	0x40040000	(1 << 0)

None of these headers has an in-tree consumer yet, which is why this has gone
unnoticed; each clash surfaces as a "..." redefined warning the moment a
driver includes the header. Code that included one of them and used the
register by name would dereference 1 or 0x1000 rather than the register.

Changes

Two of the POWMAN clashes were plain duplicates. Per the RP2350 datasheet
BOD_CTRL bit 12 is ISOLATE and DBG_PWRCFG bit 0 is IGNORE, and
RP23XX_POWMAN_BOD_CTRL_ISOLATE / RP23XX_POWMAN_DBG_PWRCFG_IGNORE were
already defined with those exact values on the immediately following lines. The
bare names are therefore removed, with no loss of information.

While removing the BOD_CTRL line, the blank line separating the
VREG_LP_EXIT group from the BOD_CTRL group is restored — its absence is
what allowed the duplicate to hide inside the preceding group.

The other four are single-field registers whose field carries no separate
name; the datasheet and the SDK describe each as a one-bit register (the SDK
exposes only the register-level _BITS, 0x1). Their bit definitions are
renamed to <REGISTER>_MASK, matching the _MASK spelling these headers
already use for a field extent, and written in hex like their peers.

The rp23xx-rv copies of all three headers are byte-identical to the arm
ones apart from the include guard and carry the same clashes, so they receive
the same change. All three pairs are verified to remain in sync.

Impact

No functional change: none of the six names has a single user anywhere in the
tree, so nothing can change behaviour. This is a latent-bug and warning fix.

Testing

• Verified with grep that none of the six macro names is referenced anywhere
  in the tree outside the headers themselves, so the renames and the two
  removals cannot break any caller.
• Confirmed against the Pico SDK register headers (rp2350/hardware_regs) that
  BOD_CTRL bit 12 is ISOLATE, DBG_PWRCFG bit 0 is IGNORE, and that
  BADPASSWD, BUS_PRIORITY_ACK, PERFCTR_EN and VOLTAGE_SELECT are each a
  one-bit register with no separately named field.
• Mechanically verified that no duplicate #define name remains in any of the
  six files, and that each arm/risc-v pair is still identical apart from its
  include guard.
• Before/after build. Since none of these headers is compiled today, they
  were temporarily included from an always-built translation unit and
  raspberrypi-pico-2:nsh built both ways:
  • with master's headers: 6 redefined warnings, exactly the six above;
  • with this patch: 0 warnings, image links.
    The temporary include was then reverted and is not part of this PR.
• Independently, raspberrypi-pico-2:nsh was built with a real POWMAN consumer
  (the RTC driver in arch/arm/rp23xx: Add RTC using the POWMAN always-on timer #19526): the three POWMAN warnings before, clean after,
  with the driver still linking.
• tools/checkpatch.sh -g clean.

Note for reviewers

Two further duplicate definitions exist in these headers but are deliberately
left alone, as they are harmless rather than bugs — both redefine a name to the
identical token sequence, which is legal C and raises no warning:

• RP23XX_OTP_BASE in rp23xx_memorymap.h (both arches), same value twice
• RP23XX_DMA_SECCFG_MISC_TIMER3_S in rp23xx_dma.h (both arches), same value
  twice, differing only in a trailing comment

They are redundant lines rather than shadowed registers. Happy to remove them
too if reviewers would like this PR to leave the headers entirely
duplicate-free.

(RP23XX_IDLESTACK_BASE in the risc-v rp23xx_memorymap.h also appears twice,
but correctly so — the two definitions are in mutually exclusive
#ifndef __ASSEMBLY__ / #else branches.)

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[casaroli]

The failing sim:alsa CI job is unrelated to this PR's RP23xx register-macro changes.

The Linux (sim-01) log fails while linking the bundled LAME encoder, with unresolved x86 runtime-dispatch vector symbols including quantize_lines_xrpow_avx2, quantize_lines_xrpow_sse2, and count_bit_esc_sse2. This is the same pre-existing CMake source-integration issue seen by other PRs: the LAME CMake target omits the vector translation units enabled by its generated configuration.

The fixes are tracked separately:

• Root-cause Apps fix: audioutils/lame: Add CMake vector sources. nuttx-apps#3666
• Companion NuttX codec-header integration fix: sim/alsa: Use bundled codec headers. #19541

The two fixes were validated together with the CI-equivalent sim:alsa CMake/Ninja build. The Apps PR should merge first; subsequent NuttX PR CI runs will then use the corrected Apps master.