provide `tokio::sync::mpsc`-like communication between processes

[nick1udwig]

Currently, processes use Request and Response builders to message each other.

It would be nice to have an alternative mode of inter-process communication, modeled on tokio::sync::mpsc channels.

Proposed usage is very inspired by mpsc, but a bit different:

1. Call a function in process A, say, start_handshake_channel(to: Address) -> Channel,
2. That will send & await to the given to: Address,
3. to:Address will reply_handshake_channel() -> Channel (or something like that),
4. As a result, both sides have a channel. That channel has associated methods .send() and .receive(),
5. When .send(), put the message in a queue that can be accessed by the other side .receive()ing.

Other things that would be cool:

1. select() over a variety of channels (and perhaps await_message() as well?); this could lead to some very nice & readable logic,
2. clone_channel(to: Address): give an existing channel to another process; useful for broadcasting and/or multiple speakers to one receiver; would require that the queue not pop off the element upon read, but one queue be maintained per process.

Open questions:

1. What is scope?
2. Where does channel queue live?
3. Is it correct to do the two-way channels above or should they be one-way?
4. How much of this work should be done in kernel vs at process_lib level?

Proposals at answers:

1. No cloning, but design queues in a way that they can be extended to cloning, if possible,
2. Not certain; the answer to this makes it easy/hard to extend to cloning,
3. I like two-way, but one-way is likely simpler; it'd just lead to more code for devs who want to use two-way,
4. Not certain.

[nick1udwig]

More thinking here https://gist.github.com/nick1udwig/60c689bbc084f5aa655b16ae8b1c211d