drivers: add nRF24L01+ driver

[matpala]

Adds a polling driver targeting the nRF24L01+ and Si24R1. Part of #1069.

• Supports concrete device types and the base interfaces through vtables.
• Uses pipe 0, a shared 5-byte TX/RX address and fixed 1–32-byte payloads at 1 Mbps, with 2-byte CRC, auto-ack and up to 15 retransmissions. Preserves TX power bits and validates channel and payload size before hardware access.
• Provides listening controls, blocking acknowledged sends and polled receives. Send and receive buffers must match the configured payload size.
• Unit tests check command bytes, final CE states, accumulated delays, validation and send/receive outcomes.

Requires mode-0 SPI with CS controlled by connect/disconnect, writev and writev_then_readv, plus CE and clock devices. Call apply after power-on reset and stop listening before sending.

Output parameters work around AVR issue zig#37099 in Zig 0.17.0; the fix is for 0.17.1. STATUS is read with R_REGISTER. This PR does not depend on #1077; using full-duplex transfers would require that API to merge, adapter support and a driver update.

Tested on an Emakefun RF-Nano V3.0: the rf-nano-v3_spi_nrf24 example now uses the driver through minimal local adapters (SPI with CS, CE and a busy-wait clock). With no second radio, each send reports [no ACK] (error.MaxRetries). ATmega328P driver adapters with a Timer0 clock, and a two-radio send/receive example, are planned next.

[Grazfather]

Can you adapt your example to use this driiver?

[matpala]

Done: spi_nrf24 now uses the driver (zero-cost mode) with small local adapters for the SPI, CE and a busy-wait clock, since the port has no timer clock or drivers.zig yet. Tested on the RF-Nano V3: with a single radio each key press reports [no ACK], as expected.

[Grazfather]

How are these determined?

[matpala]

These are manually encoded expected bytes for this configuration, using the nRF24L01+ Product Specification v1.0 (§8.3.1, Table 20; §9.1, Table 28). Register writes use 0x20 | address; 0x06 reads RF_SETUP, and 0xE1/0xE2 flush the FIFOs. The data reflects the configuration and test inputs: CONFIG 0x0E enables two-byte CRC and power, RX_PW_P0 uses the default 32-byte payload, and RF_SETUP becomes 0x07 from the simulated 0x0F readback. The expected array uses literals instead of the driver's encoding constants, so encoding errors can fail the test.

[mattnite]

The expected array uses literals instead of the driver's encoding constants, so encoding errors can fail the test.

I don't get what you mean by this, explain

[Grazfather]

I think he/she means that it's not written in terms of the constants and such because otherwise the test would basically be testing something like assert(send command STATUS sends command STATUS)

[matpala]

Yes, exactly, thanks @Grazfather. For example, if command.w_register were accidentally set to 0x40 instead of 0x20, the driver would send 0x40 for a CONFIG write. If the expected bytes reused that constant, they would also contain 0x40, so the comparison would pass despite the bug. Keeping the expected byte as 0x20, taken from the datasheet, makes that comparison fail and catches the mistake.