Multi-encoder proposal

[cseufert]

To support deflate, gzip, brotli and zstd compression, it currently requires stacking the middleware, which means that each request needs to go through up to 4 middleware, which means 3 extra stack frames to wade through when debugging, etc.

I propose we refactor the middleware a CompressionEncoder class that takes a list of compressors, in your preferred priority order, and the middleware finds the first supported compressor and encodes the output accordingly.

We can then provide API compatible shim classes for backwards compatibility that extend/wrap the CompressionEncoder class, and configured it with deflate/gzip accordingly.

I am going to implement this internally and was wondering if you are interested in merging it as a v3.0 type feature.

[cseufert]

Have put together a basic idea of what this could be in #6