Producer sink

[svroonland]

Implements #34

Heavily inspired by Alpakka Kafka of course.

[iravid]

There are two optimal ways to drive a producer from a stream:

• Use aggregate/aggregateWithin, as you've hinted in the comment, and produce chunks to the producer. This amortizes the cost of waiting for the producer to flush. In code: .aggregate(groupingSink).mapM(produceChunk)
• Use mapMPar, and produce individual records. The producer transparently buffers records so this is equivalent in a sense to the previous bullet. Possibly less efficient. In code: .mapMPar(parallelism)(produce)

Neither of these are possible with a pure Sink-based API. The problem is that we don't have any other way to offer users a stream "segment" from our library code.

For now, I suggest that we instead add additional documentation with recommendations on how to efficiently produce data.

[svroonland]

@iravid Thanks for your feedback.If I understand correctly, then all we can offer is the two sinks like in the updated PR. Is that according to your original ideas?

[iravid]

Yes, this is the based we can do right now. However, I would delete the one that produces individual records, because it's going to be very inefficient. Let's just offer the one that produces chunks for now.