!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.
I figured that I was probably wrong about needing `flatten(Concat)` to fix the zip bomb problem. If we make the Deflate.Decompressor an Op and we can react to demand directly I think I can fix it there. To summarize my current thinking:
 * For all current purposes (coding and Range support) having the API work on Op directly should work
 * Executing this Op synchronously, would allow to make the `Strict` case map to `Strict` again. This, however, will again create the risk of a zip bomb. One mitigation could be to limit the number of iterations the interpreter runs and if it doesn't conclude provide a workaround path that again falls back on Chunked/asynchronous execution.
 * The current `Chunked.transformDataBytes` handling seems natural but I think it is only roughly specified and probably overkill for common use-cases I can think of. I would simplify it for now. If tight control over chunks of an entity is needed it is still possible to implement it manually.
 * I see `transformDataBytes` as user API and, therefore, I'd rather make it more generic than it is currently and have it work on `Flow`, instead. This would mean that we either let go of the `Strict` optimization or we'd need to resurrect a potential synchronously Op out of a Flow at runtime.