Refactor Mem2Mem driver

[Dominaezzz]

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 API guidelines

Extra:

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

Pull Request Details 📖

Description

Part of #2269 .

Two big changes here:

• I've split the Mem2Mem driver into an RX half and a TX half. Each half could be sent to a different task.
• I've added support for DmaTxBuffer/DmaRxBuffer.

A nice side effect of this is that the driver can now be used as a queue/channel to communicate between tasks. (Dunno if anyone would do this in practice)
It also allows us to easily HIL test DmaTxBuffer/DmaRxBuffer implementations.

Testing

Ran HIL tests and examples

[bugadani]

The "I have to fill a buffer so that I can avoid using the CPU to copy, then copy out of that buffer" seems to be missing the idea of why someone would use mem2mem in the first place. This whole API should be, from a user's point of view, a single memcpy-like function that takes a slice, and puts it in a different, mutable slice. Whether that, then, returns a handle with a .wait() or a future that can be awaited, doesn't matter.

If you need two buffers to do mem2mem, you might as well fill one, and swap pointers without the need for DMA.

[Dominaezzz]

If you need two buffers to do mem2mem, you might as well fill one, and swap pointers without the need for DMA.

Wasn't the existing API doing this already? I'm not sure I understand what you mean.

This whole API should be, from a user's point of view, a single memcpy-like function that takes a slice, and puts it in a different, mutable slice.

I don't agree that this whole API should be just that, that would be too opinionated of an API. Though, if PSRAM weren't in the picture I would've agreed.
In my project I use DMA memcpy to workaround PSRAM bandwidth limitations (basically an async version of the "bounce buffers" in esp-idf).

I hear what you're saying though, so I can add a (secretly unsafe, like the existing API) wrapper on top of this API that takes two slices, for those that want to do the simple thing.

[Dominaezzz]

Unfortunately DmaRxBuf doesn't support PSRAM yet so a wrapper won't be trivial. I'll come back to this later.