Consume POLL body to ETX before replying to avoid RS-485 bus contention

[brocci]

As reported in issue #28:

[SPEC-DEVIATION] Poll is answered without verifying the poll's ETX — now with real collision exposure

• Status: still present in v1.7.0, consequence elevated by the v1.5.1 delay change.
• Spec: LCS-9.10.1 p.7 §D.2 (poll format includes ETX); p.2 ("Any sequence of bits not meeting the full specification of this general message format is not ... a valid message"); p.4 §C (half-duplex network).
• Code: src/CMRI.cpp:204-205 (goto POSTAMBLE_POLL on the P byte itself), src/CMRI.cpp:258-260, src/CMRI.cpp:147 (delayMicroseconds(50)).
• The node commits to transmitting its R reply the instant it sees P, before the poll's ETX has been received or checked. A corrupted frame (FF FF 02 UA P <noise>) still gets a full response. In v1.5 the 50 ms delay() masked the timing race; in v1.7.0 the reply starts ~50 µs after the P byte — while the host's ETX (~1.04 ms at 9600 bps) is still on the wire. On the spec's four-wire network the pairs are separate so no electrical collision occurs, but on the common 2-wire RS-485 setups this library is explicitly marketed for (Auto485 examples, examples/rs485_rx_and_tx/rs485_rx_and_tx.ino) the node's driver can be enabled while the host is still transmitting — a genuine bus-contention window of about one character time.
• Fix: add a POSTAMBLE_POLL_WAIT_ETX state; reply only after ETX is received.

This PR implements the required fix and adds corresponding tests.
The fix does not use a POSTAMBLE_POLL_WAIT_ETX additional state as suggested above, but reuses existing IGNORE_DATA and a small change in POSTAMBLE_IGNORE.