[arnetheduck]

By separating the handles responsible for the two sides of a channel, we get to support an intuitive api for closing channels that is safe by construction, ie there's no risk that senders write into a channel closed for sending and vice versa.

Both receivers and senders can be copied and moved around so that they can each be shared by multiple threads.

The principle of operation is simple:

• senders and receivers have separate refcounts on the raw channel
• with all senders gone, it means no more items will be pushed to the channel - all queued receivers are woken up and told it's over (once they've drained the channel)
• with all receivers gone, it means no more messages can be pushed into the channel - we can free the buffer and sending becomes a no-op
• with both gone, we release the channel resources.

On the sending side, we return a bool for "no more receivers" - on the receiving side, we return default(T) or a bool for the var-taking version - both sides can check if the channel was closed to disambiguate.

[Araq]

I need to fix the CI first, seems ready to go otherwise.

[arnetheduck]

fix the CI first

Well, we can't meaningfully use createShared until 2.2.12 so probably the older versions will have to go away or #77 should be reverted for those version.

when bumping, atomics should probably be removed, but memory ordering is broken and needs fixing before it's meaningful to use.

[arnetheduck]

#91 is blocking this for now

[arnetheduck]

So this is now minimally correct with respect to #91 at least, via a destructor call in the lock - not the best in terms of efficiency, but in line with other inefficiences already present (copying/destroying/etc inside the contended lock).