Refactoring RF channel state machine

[ryan-summers]

This PR refactors the RF channel state machine to use smlang.

This PR fixes #171

[ryan-summers]

@jordens Hold off on review for this one. There's some improvements I'd like to implement first to simplify the design.

[ryan-summers]

Hmm... After playing around with the code for a while, a significant refactor of the statemachine to utilize the guards and actions provided by smlang would require us to turn the RfChannel code on it's head, as the statemachine object would own the RfChannel object instead of the other way around (as is currently implemented).

[jordens]

Sounds like it may be worth it.
Maybe just impl StateMachineContext for RfChannel and the let the channel be the context?

[ryan-summers]

Yeah, the main problem is that anything that was previously interacting with RfChannel now has to instead use the state_machine.context_mut().<code> instead, and I'm trying to figure out a nice way to avoid a ton of boilerplate.

[jordens]

Don't most callers go through this single code path anyway?

booster/src/hardware/booster_channels.rs

Line 97 in 2501f4d

pub fn map<F, R>(&mut self, channel: Channel, func: F) -> Result<R, Error>

[jordens]

Looks very good to me. Let's merge now and handle remaining and arising issues later and through #178

[ryan-summers]

Bench testing and button mashing indicates the statemachine is operating as I would expect it to, and I do not see a discernible difference from previous behavior.