RMT: Make PulseCode a newtype rather than an extension trait

[wisp3rwind]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the Migration Guide.
• My changes are in accordance to the esp-rs developer guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

This is on top of #3716, only the last commit is new.

This PR proposes to convert the RMT PulseCode, which is currently an extension trait implemented for u32, to a newtype struct PulseCode(u32).

This has several advantages, as outlined in the commit message:

RMT: make PulseCode a newtype rather than an extension trait on u32

This has several advantages:

• the meaning of u32 used as pulse code becomes more explicit
• it allows using PulseCode methods in const context (which is otherwise
  not possible because Rust does not presently support associated const
  fn in traits).
• it allows providing custom defmt::Format and core::fmt::Debug impls
  for PulseCode, greatly helping with debugging

I have taken the liberty to implement core::fmt::Debug in a slightly
non-standard way: The most natural implementation would probably use a
struct-style output like

PulseCode { length1: 42, level1: Level::High, length2: 24, level2: Level::Low }

However, that is very lengthy and not really human-readable anymore when
dealing with an array of PulseCodes. Thus, this uses the more compact format

PulseCode(H 42, L 24)

This provides u32: From<PulseCode> and PulseCode: From<u32> impls and
converts rx and tx methods to accept impl Into<PulseCode> and
impl From<PulseCode>, respectively.
This should help to reduce how much user code needs to change (but replacing
u32 type annotations with PulseCode will be required).

Testing

As part of #3509 in CI and locally for esp32c3.

[bugadani]

Do we need this? Won't this cause confusion?

[wisp3rwind]

Originally, I had simply renamed this to end_marker; then I returned to it and was unsure whether it was worth it in the face of backwards-compatibility, and because end_marker does not necessarily correspond to user intent (e.g. if initializing an rx buffer).

I think there are two uses for 0-valued pulse codes:

• terminate a tx buffer: tx_data[tx_data.len() - 1] = PulseCode::end_marker()
• initializing an rx buffer: let mut rx_data: [_; 42] = [PulseCode::empty(); 42]

and 3 ways to generate them

1. PulseCode::end_marker()
2. PulseCode::empty()
3. PulseCode::default()

which, as you say, seems likely to generate confusion.

I'd argue that it might be best to keep 1) and 3), allowing to express both uses in a meaningful way. What do you think?

[wisp3rwind]

Just pushed an updated branch with .empty removed and an addition to the migration guide concerning these methods.

[wisp3rwind]

Updated with changes addressing the review and some further enhancements (see the commit message for a full listing of changes compared to the previous version); rebased on main.

[bugadani]

Sorry, I forgot about this. Let's see how this turns out :)