Rename channel to mpmc

I've renamed the channel module for the MPMC as mpmc. There was a previous debate about this, but I feel that the strategy here avoids importing `channel::channel`. The change leaves `signal::Signal`, but I think that's ok. It is all a bit subjective of course. The bottom line for me is that I really like the term mpmc - it means something to me and aligns with broader naming e.g. in Tokio.

embassy/src/channel/mod.rs

@@ -1,7 +1,5 @@
 //! Async channels
 
-pub mod channel;
-pub use channel::*;
+pub mod mpmc;
 
 pub mod signal;
-pub use signal::*;

embassy/src/channel/mpmc.rs

@@ -388,7 +388,7 @@ where
     /// Establish a new bounded channel. For example, to create one with a NoopMutex:
     ///
     /// ```
-    /// use embassy::channel::channel::Channel;
+    /// use embassy::channel::mpmc::Channel;
     /// use embassy::blocking_mutex::raw::NoopRawMutex;
     ///
     /// // Declare a bounded channel of 3 u32s.
@@ -404,7 +404,7 @@ where
     /// Establish a new bounded channel. For example, to create one with a NoopMutex:
     ///
     /// ```
-    /// use embassy::channel::channel::Channel;
+    /// use embassy::channel::mpmc::Channel;
     /// use embassy::blocking_mutex::raw::NoopRawMutex;
     ///
     /// // Declare a bounded channel of 3 u32s.

embassy/src/channel/signal.rs

@@ -5,7 +5,7 @@ use core::task::{Context, Poll, Waker};
 
 /// Synchronization primitive. Allows creating awaitable signals that may be passed between tasks.
 /// For a simple use-case where the receiver is only ever interested in the latest value of
-/// something, Signals work well. For more advanced use cases, you might want to use [`Channel`](crate::channel::channel::Channel) instead..
+/// something, Signals work well. For more advanced use cases, you might want to use [`Channel`](crate::channel::mpmc::Channel) instead..
 ///
 /// Signals are generally declared as being a static const and then borrowed as required.
 ///