[DNM]: Stm32c5 halv2 usb rework

[fpistm]

This PR is a review/rework of the stm32duino#3059

• rebase on main branch
• remove useless USBD_V2_ErrorHandler
• remove some useless warning. Ex: #warning "USB device support is currently implemented only for STM32C5xx HAL v2.". Assume by default it should be ok.
• Remove limit CDC transmit blocks to packet size (it will be evaluate against an other PR fix(cdc): stop arming OUT endpoint with a NULL buffer stm32duino/Arduino_Core_STM32#3058).
• Remove add optional hook on CDC line coding change, see feat(usb): add optional hook on CDC line coding change stm32duino/Arduino_Core_STM32#3078. To be evaluate against feat: reboot into the ST system bootloader on a 1200 bps touch stm32duino/Arduino_Core_STM32#3063 which include same behaviour.
• introduce and fix double buffer management.

This PR is functional on Nucleo C562RE (single or double buffer).

/cc @cumin777

[cumin777]

Hi @fpistm, thanks for the rework — reviewed, tested, and force-pushed into stm32duino#3059.

Review

• Generic double-buffer management + the hal_conf/ep_conf macro interlock: cleaner than our C5-specific layout.
• Dropping the transmit clamp and the line-coding hook: agreed. We'll follow feat(usb): add optional hook on CDC line coding change stm32duino/Arduino_Core_STM32#3078 for the XIAO 1200-bps touch handoff; feat(xiao): add Seeed XIAO STM32C5 board support stm32duino/Arduino_Core_STM32#3048 will be rebased once it lands.

On hardware (XIAO STM32C5, same USB_DRD_FS IP as your C562RE)

• Both the default double-buffer and the -DUSBD_CDC_USE_SINGLE_BUFFER builds compiled clean (HAL v2 adapter in artifacts).
• Flashed and enumerated; CDC TX-RX verified: AT round-trips, +READY 170 ms after DTR, 64KB echo loopback with zero bit errors (~267 KB/s).
• Two 5-minute stability runs: 60/60 heartbeats, ~88 MB loopback traffic, no re-enumeration.

Observation on the XIAO (follow-up needed)

• Single write() bursts above ~256 bytes intermittently echo fewer bytes than sent (e.g. 320/512, 640/1024, always a multiple of 64); ≤256 B writes are lossless across 88 MB.
• Present identically in the pre-rework revision of this PR, so not introduced by the rework itself — but both revisions carry the new HAL v2 USB adapter, so I can't yet tell whether it's an adapter-level issue. I'm tracing which direction drops (RX vs TX) and will follow up.

ARM64 and other hosts remain untested on my side, as before.

[fpistm]

Thanks @cumin777

About your issue, could you try with this PR:
stm32duino#3058

[cumin777]

Context. Stress-tested the CDC path on XIAO STM32C5 (HAL v2 / DRD IP, rework from
stm32duino#3059) with a verbatim-echo sketch under sustained PC→device traffic (Windows 10,
usbser): deterministic per-block data, per-block compare, 5-min runs (~92–100 MB each),
256 B / 1 KB blocks.

stm32duino#3058 verified on C5. With stm32duino#3058's two commits on top of the rework: ladder
16–1024 B ×10 = 50/50, size sweep 320/384/448 ×10 = 30/30, short-packet probe (fixed
odd sizes 300–2044 ×15 + 500 random 1–3000) = 575/575, 100 MB × 1 KB and 92 MB × 256 B
with zero errors. Notably, the stm32duino#466 scenario (final short packet while the RX queue is
full) does not reproduce on this IP, even in single-buffer mode.

New finding: rare RX endpoint stall in double-buffer mode. Present with stm32duino#3058
applied and unaffected by anything we tried at class level:

firmware (rework +)	bulk OUT mode	result
stm32duino#3058	double buffer	stall after 96 MB (earlier session: 192 MB clean)
stm32duino#3058 + explicit NAK on queue full	double buffer	stall after 91 MB
stm32duino#3058 + NAK guarded off for DB	double buffer	stall after 6 MB (a 99 MB 256 B run clean)
stm32duino#3058 + IRQ-masked re-arm	double buffer	stall after 70 MB
any build above	single buffer	no stall in any test

Failure mode: echo stops mid-block (e.g. 894/1024 bytes echoed), zero bit errors before
the stall, device stays enumerated; in the case we rechecked it recovered after the
host closed/reopened the port.

Since neither class-layer backpressure nor masking the re-arm against the USB IRQ
changes it, this points at the HAL v2 double-buffer receive path itself
(HAL_PCD_EP_DB_Receive ping-pong bookkeeping) rather than the CDC class.

Suggestion. Until the DB receive path is investigated, defaulting the CDC bulk OUT
endpoint to single buffer on this IP looks safe per our data (single buffer was clean
in every test, including the stm32duino#466 short-packet scenario). Happy to share test scripts
and firmware details.

[fpistm]

Yes. Please share.
I've merged the revert of stm32duino#466. I think to add a NAK when the buffer is full.