`oneshot` Channel
Tracking Issue: https://github.com/rust-lang/rust/issues/143674
This PR adds an experimental `oneshot` module.
Before talking about the API itself, I would prefer to get some of these questions below out of the way first. And as discussed in the [ACP](https://github.com/rust-lang/libs-team/issues/610) it would be
# Unresolved Questions
- [x] ~~Why exactly is it okay for `Sender` to be `Sync`? Or basically, how do we boil down the discussion in https://github.com/rust-lang/rust/pull/111087 into a comment for the `unsafe impl<T: Send> Sync for Sender<T> {}`?~~
- [x] ~~Why is `mpsc::Receiver` `!Sync` but `mpmc::Receiver` is `Sync`? Should `oneshot::Receiver` be `Sync` or not?~~
- [ ] Should this PR try to add an `is_ready` method as proposed in the tracking issue? If so, then the surface of this PR would likely need to increase to add a `pub(crate) fn is_disconnected` method to `mpmc` (might even be a good idea to add that to all 3 channel flavors).
- [ ] In a similar vein to the previous question, should the first internal implementation simply be a wrapper around `mpmc`, or should it be a wrapper around the internal crossbeam implementation?
- [ ] Should the `Sender` and `Receiver` operations be methods or associated methods? So `sender.send(msg)` or `Sender::send(sender, msg)`? The method syntax is more consistent with the rest of the ecosystem (namely `tokio`)
b7bcaa5c71