Migrate to compiler-managed state

[2bndy5]

The main idea here is to take advantage of the rustc compiler's zero-cost abstractions.

Tip

See example in the embedded-rust book.

What does this mean?

The user code will manage the state of a radio object in a way that the compiler can keep track and prevent undesired behavior.

Here's some pseudo (user-space) code that should explain better:

let mut radio = RF24::new(ce_pin, spi_dev, delay_impl);
// mutate the radio object so that it is in TX mode with auto-ack enabled
radio = radio.init()?;

// `available()` and `read()` are exposed as a TX node.
let mut payload = [0u8; 32];
if radio.available()? {
    radio.read(&mut payload)?;
}

// `send()` and `write()` are also exposed as a TX node
let ok = radio.send(&payload, /* ask_no_ack */ false)?;

// mutate the STATE of the radio
radio = radio.as_rx()?;

// `send()` and `write()` are NOT exposed as a RX node, so
// this line would fail to compile
//let ok = radio.send(&payload, false)?;

The state management can be further extended to some radio features like power up/down, auto-ack, dynamic payloads, ACK payloads, etc. The main advantage here is that we no longer have the runtime overhead for checking the radio's settings for validity according to the invoked behavior; send() will not need to check the CONFIG register's PTX and PWR_UP flags.

Considerations

1. Addressing this is nothing short of a refactor (likely a complete API overhaul). Additionally, this solution may impact the convenient configurable API introduced by Consider abstracting config out of radio instance #5.
2. The bindings (both python and node.js are scripting languages that use dynamic types) may suffer additional overhead because the state would be managed dynamically at runtime (as it does currently).

[2bndy5]

I'm abandoning this idea. It doesn't seem worth it because

1. Using data types to track the state of something means the user code would have to re-allocate memory for the same object with a new state.
2. The runtime overhead we'd be avoiding isn't significant enough to force users to beware of the radio's state (via various data types noted in point 1)