std: Second pass stabilization for comm

[alexcrichton]

This commit is a second pass stabilization for the std::comm module,
performing the following actions:

• The entire std::comm module was moved under std::sync::mpsc. This movement
  reflects that channels are just yet another synchronization primitive, and
  they don't necessarily deserve a special place outside of the other
  concurrency primitives that the standard library offers.
• The send and recv methods have all been removed.
• The send_opt and recv_opt methods have been renamed to send and recv.
  This means that all send/receive operations return a Result now indicating
  whether the operation was successful or not.
• The error type of send is now a SendError to implement a custom error
  message and allow for unwrap(). The error type contains an into_inner
  method to extract the value.
• The error type of recv is now RecvError for the same reasons as send.
• The TryRecvError and TrySendError types have had public reexports removed
  of their variants and the variant names have been tweaked with enum
  namespacing rules.
• The Messages iterator is renamed to Iter

This functionality is now all #[stable]:

• Sender
• SyncSender
• Receiver
• std::sync::mpsc
• channel
• sync_channel
• Iter
• Sender::send
• Sender::clone
• SyncSender::send
• SyncSender::try_send
• SyncSender::clone
• Receiver::recv
• Receiver::try_recv
• Receiver::iter
• SendError
• RecvError
• TrySendError::{mod, Full, Disconnected}
• TryRecvError::{mod, Empty, Disconnected}
• SendError::into_inner
• TrySendError::into_inner

This is a breaking change due to the modification of where this module is
located, as well as the changing of the semantics of send and recv. Most
programs just need to rename imports of std::comm to std::sync::mpsc and
add calls to unwrap after a send or a receive operation.

[breaking-change]

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

This is temporarily rebased on #20157 due to the high number of conflicts, the only relevant commit is the last one.

[flaper87]

@alexcrichton you may also want to add RacyCell in the things to mark in this PR. I believe it's still experimental as we still don't know if the current implemented methods are the ones we'd like to keep around. However, I'd probably move it to stdy::sync instead of keeping it in std::sync::comm

[alexcrichton]

I've updated this by removing all reexports in std::sync and renaming the comm module to mpsc. @aturon and I discussed and we think that this should allow for more channel implementations to be added in the future and it clearly spells out what the channel implementation is supposed to be used for.

@flaper87 I don't think RacyCell is public (and I'd like to keep it that way), so we don't have to worry about it too much during staiblization.

[flaper87]

@alexcrichton yeah, it isn't and shouldn't be public. I thought we wanted to also stabilize our internal types too. However, I still think we should move it to std::sync, it could be used in other places in sync instead of things like Packet

[aturon]

OK, I've reviewed this and largely looks good, but I had some concerns about some of the new error types. Once those are addressed, r=me.

[alexcrichton]

I'm going to hold off the r+ until #20157 lands, but once it does I will r+ this.