Introduce broadcast() extension to turn ReceiveChannel into BroadcastChannel

We need a broadcast operator that turns a ReceiveChannel into BroadcastChannel.

[elizarov]

@caleb-allen Channels are quite an orthogonal concept to reactive streams. Channels come from CSP (Communicating Sequential Processes) world. In that worlds channels are things that you are supposed to share between communicating processes. Channels are like queues – send at one and and receive on the other end. They are very much unlike reactive streams in many respects.

However, when we start expanding the repertoire of channels that we support (like broadcast channels discussed here) we inevitably somewhat encroach onto the territory of reactive streams which sometimes results in confusion.

Channels are not something that reactive streams might readily benefit from, but Kotlin coroutines and suspending functions in particular is something to watch for. See, reactive streams specification is quite involved precisely because it is designed to work around the lack of suspending functions in Java. Reactive streams is a clever hack to support asynchronous data streams in a language that does not support asynchrony natively. That is why Kotlin’s only interest in reactive streams is from interop standpoint. We have all sorts of adapters with reactive streams, but there is no much benefit in using them in Kotlin as is.

[elizarov]

@caleb-allen For asynchronous functions returning a single result we have a robust language feature (suspending functions). For asynchronous streams of values we still need something in the library. Given that asynchronous functions are natively supported in the language, this library’s design will be necessary different form reactive streams (see #254).