+htp #16516 rewrite Deflate/GzipDecompressor as StatefulStage to defuse zip bomb

The GzipDecompressor now looks quite nice, very similar to the one before, but it was quite a ride to get there... Thanks to quite a good test coverage I'm somewhat confident it's now correct.

/cc @sirthias
The main problem is here that for a suspendable parser one needs to be able to provide continuations after every step (byte) if the current input runs out. Iteratees have shown that this is possible to do in a functional and composable way which is also very slow. An alternative solution would have to provide some kind of state machine with many entrypoints which isn't feasible to write manually (and also not composable). A parser generation approach may lead us there eventually but we are not there yet. Do you have any better ideas?

The approach here allows for quite readable code, is composable (though not in a functional way), and should be quite efficient because the cost of throwing an exception (which isn't very big anyways) is amortized over the complete batch of bytes coming in with a ByteString. If the parser is run as a synchronous pipeline the interpreter should be in control of batch sizes and can therefore control the trade-off between memory usage and throughput quite easily.