!str #15236 new transformer

This is far from finished, but I need to discuss.

The end goal of this is to provide a powerful, efficient, low level API for custom transformation operations. It is supposed to replace `Transformer`.

So far this is only using the API of the `impl.fusing.Op` (and subsclasses). These will be made more user friendly where needed. We can also consider providing higher level API that is more convenient for certain type of operations.

As first step I'm replacing all existing `Transformer` usage.

I'm currently stuck in `HttpEntity` and we must discuss how to go forward there. @jrudolph @sirthias should be part of that discussion.
Ok, I agree that any streams that transport batches of elements (like ByteStrings) which define a natural join operation may warrant a special interface that simplifies writing a transformer for it. For me `ByteStringTransformer` is not more than an implementation help for writing a Transformer on ByteStrings.

> Are these assumptions correct for these ByteString transformers?

I cannot say what kind of transformers users come up with. Therefore, it would be nice if we could keep the interface of `transformDataBytes` as generic as possible. Using `Flow[ByteString, ByteString]` as I suggested probably doesn't work because we would have to give up the optimization in the `Strict` case and streams don't have any abstractions for work that can be done strictly. Why can't the interface stay at a generic `Transformer[ByteString, ByteString]` though, where you **can** use the new `ByteStringTransformer` as an implementation help but you don't have to?