Heh, so this doesn't even work remotely as planned 😂

Turns out receive mem chans do not support broadcasting in trio:

The clones all share the same underlying channel. Whenever a clone receive()s a value, it is removed from the channel and the other clones do not receive that value. If you want to send multiple copies of the same stream of values to multiple destinations, like itertools.tee(), then you need to find some other solution; this method does not do that.

This actually ended up being a source of major confusion in pikers/piker#158 where this PR's change to ReceiveStream.aclose() was actually preventing far end producer cancellation and then a very hard to debug back-pressure instigated lockup 😂

So basically I think we need to drop this idea wholesale (at least if we're sticking with clone as it has meaning in trio) and instead venture into what we're actually after: broadcast channels as in python-trio/trio#987.

See also #53 for further discussion on how we don't want trio's .clone() semantics (since it isn't useful cross-process).