HTTP: support multiple Content-Encodings

This is implemented as an output streaming stack of unencoders, the last
calling the client write procedure.

New test 230 checks this feature.

Bug: #2002
Reported-By: Daniel Bankhead

docs/INTERNALS.md

@@ -673,7 +673,7 @@ Content Encoding
 
  where string is the intended value of the Accept-Encoding header.
 
- Currently, libcurl does not support multiple encodings and only
+ Currently, libcurl does support multiple encodings but only
  understands how to process responses that use the "deflate" or "gzip"
  Content-Encoding, so the only values for [`CURLOPT_ACCEPT_ENCODING`][5]
  that will work (besides "identity," which does nothing) are "deflate"

docs/TODO

@@ -67,7 +67,6 @@
  5.7 Brotli compression
  5.8 QUIC
  5.9 Leave secure cookies alone
- 5.10 Support Multiple Content-Encodings
 
  6. TELNET
  6.1 ditch stdin
@@ -538,12 +537,6 @@ This is not detailed in any FTP specification.
 
  https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01
 
-5.10 Support Multiple Content-Encodings
-
- RFC 7231 Section 3.1.2.2 allows multiple encodings for a single request. Using
- this may result in lower bandwidth and promotes a more resource-friendly web.
- Currently, Chrome and Firefox support multiple encodings.
-
 
 6. TELNET