This is a second attempt at allowing longer pulse sequences to be recorded using pulseio.PulseIn on espressif ports using the DMA backend of the RMT hardware.

This is essentially the same code as in the original PR #10397, but the new logic is now only activated in cases where the existing logic didn't work, i.e. if maxlen > 128. I believe this fixes all issues raised in #10466 and #10470:

• If maxlen <= 128, then the old logic works fine on all ports.
• If maxlen > 128 and the DMA backend is available (i.e. the hardware supports it and it is not allocated), then recording longer pulse sequences works.
• If maxlen > 128 and the DMA backend is NOT available (i.e. the hardware doesn't support it or it is already allocated, e.g. due to an existing PulseIn object), then a "Invalid maxlen" error is raised. In this case, using maxlen <= 128 still works.

I tested all of this on a Lolin-S2-mini and a Waveshare-S3-Zero and added a sentence to the documentation regarding this.

Notes:

1. This is a breaking change to anyone previously using maxlen > 128 on a variant that did not support it. Previously this silently just returned shorter sequences, now this raises an error.

2. I think it might be possible to get maxlen > 128 to work also on variants without DMA hardware because the documentation says:

   Usually, only one block of 64 x 32-bit worth of data can be sent or received in channel n. If the data size is larger than this block size, users can configure the channel [...] to use more blocks by setting RMT_MEM_SIZE_CHn

   But this might introduce more limitations regarding use of multiple PulseIn and PulseOut, which is a can-of-worms I did not want to open in this PR.

3. Strictly speaking the value of 128 above should be replaced by 2*SOC_RMT_MEM_WORDS_PER_CHANNEL. But since this was previously hard-coded to a maximum of 128 pulses (with only worked due to Note 2), and changing this would be another breaking change, I left this at 128.

Maybe @jbrelwof and @bill88t want to try this out before it gets merged.