[Channels] implement AsyncBufferedChannel

[twittemb]

Hi.

This PR is a draft implementation of the variant to AsyncChannel mentioned in this thread -> https://forums.swift.org/t/asyncchannel-should-we-allow-to-buffer/60876/12

Here the description:

/// A channel for sending elements from one task to another.
/// The back pressure is handled by buffering values until a limit is reached
/// and then by suspending send operations until there are available slots in the buffer.
///
/// The `AsyncBufferedChannel` class is intended to be used as a communication type between tasks,
/// particularly when one task produces values and another task consumes those values.
///
/// Although the `send(_:)` function is marked `async`, it will suspend only if the internal buffer is full.
/// It will be resumed when a call to `next()` frees a slot in the buffer.
///
/// The `finish()` function marks the channel as terminated. The buffered and suspended elements
/// will remain available and dequeued on calls to `next()`.
/// In this terminal state, a call to `send(_:)` will resume immediately and the element will be discarded.

As discussed in the forum, it does not necessarely target the v1.0.

That being said, I think we can reuse the same kind of implementation (state machine / storage / async sequence) for AsyncChannel as it better separates the concerns and it is now the "default" implementation when there is a shared state to manage between producers/consumers or racing tasks.

Also, as mentioned here -> https://forums.swift.org/t/pitch-async-buffered-channel/59854/9 we might want to move away from the "all-in-one" paradigm in favour of a pair continuation/async sequence as pitched by @FranzBusch for AsyncStream. In that case the implementation is still valid by reusing the storage in both parts.

I have intentionally not implemented the throwing version waiting for more feedback from the community.

@phausler @FranzBusch I guess you are the ones that can review it when this is the right timing.