Interloop (trio <-> asyncio) memory channel design

[goodboy]

With the completion of #121 we now have a way to wrangle asyncio code
from SC-actor-land.

One of the obvious ugly parts of the current api is the delivery of an
asyncio.Queue to the target asyncio task. In keeping with trio
style it would be much better to offer a small abstraction much like
trio.abc.Channel to make asyncio-side streaming semantics more
elegant.

We already introduced a LinkedTaskChannel as part of #121
for the trio side and it would be handy to have something equivalent
for asyncio tasks.

---

Some design options:

• make two types of LinkedTaskChannels, one for each task in each loop
  • probably allows the most flexibility for the apis allowed from either task and is most explicit type-wise?
• universal queue ideas from the trio peeps:
  • orig by njs: https://gist.github.com/njsmith/3494ebd27f32c2ac168c71de116ccc5d
  • fixes from richardsheridan: https://gist.github.com/richardsheridan/8f803a5a15831840846083a6cbcefbea
• adopt either directly or by inspiration some stream apis from anyio?
  • we could adopt a stapeled stream style where we dynamically figure out which loop the channel object is being used in and then runtime-define the methods implementations? This might allow for a more symmetric channel api/object at the expense of some magical method definitions?
• consider adding a .started() method to whatever the asyncio-side channel type ends up being much like the anyio.from_thread.BlockingPortal.start_task()/trio.Nursery.start() target function mechanisms. This would allow us to avoid the current manual first-sent-value-ublocks-the-trio side to_asyncio.open_channel_from() entry.

Very open to and interested in other ideas (and further discussion) from the lurkerz.