[PATCH v2] Add support for gzip content decoding

Support decoding of the gzip Content-Encoding in responses using the
zlib module to decode the response before piping it through the request
object (and therefore before user-connected pipes or body parsing).

Add the boolean option `gzip` to allow users to explicitly
request decoding of supported response content and inclusion of
appropriate content negotiation headers, if unspecified.

This commit favors backwards-compatibility over the increased
performance that transparent compression could provide, although it is
hoped that a future backwards-incompatible version can make transparent
compression the default.

Some major tradeoffs of transparent compression are:

- It may trigger changes in server behavior and performance (for better
  or worse) that are unexpected, either due to buggy servers or
  intermediate network hardware.
- The compression is not fully transparent as users who attach to the
  `data` event of the response (rather than the `data` event of
  `request`) will get gzipped data rather than uncompressed data.
+ It is likely a big win for most users (both current and future) who
  would otherwise be unaware or unable to spend the time to implement
  content negotiation and decoding.  Especially given the prevalence of
  highly-compressible text content (e.g. JSON and XML) and widespread
  server support for gzip.

Changes since v1:
- Rename `decodeContent` option to `gzip` to match option name in 3.0

Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
WIP: Support deflate in addition to gzip

When the `gzip` option is `true`, also support the `deflate` compression
algorithm.

This patch is a work-in-progress and does not currently work for
non-confirming "raw" deflate data.

Signed-off-by: Kevin Locke <kevin@kevinlocke.name>