Implement new RMT driver API

[Luro02]

Motivations

• Would you like to implement this feature? [y]

The current implementation is feature-gated on the rmt-legacy feature and will likely be removed in the future.

I have several issues regarding usability, like not being able to supply a loop of more than 1023 elements or asynchronously awaiting for the transmission to be sent.

Solution

Implement the new driver API, and fix the soundness issues (mentioned in other issues) while at it.

I already have a proof of concept for the TxDriver, but it isn't finished yet, hence no PR for now. I am planning to submit it in the next few months.

Some issues that have to be taken care of;

• Allow sending a signal without waiting for it to be finished. This is useful to repeatedly queue multiple signals, not having to wait for each one to finish and some signals like Loop::Endless would otherwise result in a not returning function.
• Decide on how to deal with encoders. Encoder are used to translate arbitrary types to rmt_symbol_t. They have to be passed to the transmission method, which will call the encoder functions from an ISR context. Todo: How about calling the encoder before sending it to the driver? Are there any disadvantages?
• Prevent any unsoundness issues, especially of note are: The signal and encoder must be available until the transmission is sent, the callbacks have to be ISR safe
• Decide on a good approach to await transmissions individually. The API only provides a function to await all transmissions to finish. To work around this issue, I decided to use the event callbacks, but they require some global state/atomics/allocations.

Alternatives

Don't do anything and wait for the inevitable removal of the API?

Additional context

[Vollbrecht]

@Luro02 feel free to push even a Draft PR early and then we can help you move forward with early feedback, e.g helping you around how things currently work in the greater schema etc .