Support for handling compressed responses in the HTTP connector

Hey guys,

This patch tries to add support for handling incoming compressed content in the http connector. The general idea is to read the chunks of the reponse in [buffers](nodejs.org/api/buffer.html) instead of concatenating them as a string (so we can support binary data), and then uncompress it if the **Content-Encoding** header is present and matches *gzip*.

The pull includes two unit tests, both pass. The first one will test the positive case, where the transport detects, uncompress, and returns a response. The second one will test the negative case where uncompressing the data returns an error (in this case, the error and the original response are returned).

Please take into account that I'm not that experienced in writing unit tests for nodejs and using these frameworks in general, but the code *seems reasonable*.

The patch has been also tested manually with ElasticSearch 1.3.2, setting:
```yaml
http.compression: true
http.compression_level: 9
```

And instantiating the client with:
```js
{
  hosts: [
    {
      host: 'localhost',
      headers: {
        'Accept-Encoding': 'gzip, deflate'
      }
    }
  ]
}
```

Any thoughts? Thanks in advance.
@spenceralger (replying to your comment about the use of unzip/gunzip that my commit wiped out, sorry):

I chose to use zlib.unzip() because it ends up [creating an Unzip class](https://github.com/joyent/node/blob/master/lib/zlib.js#L151). The [nodejs doc for the Unzip class](http://nodejs.org/api/zlib.html#zlib_class_zlib_unzip) states that it will "Decompress either a Gzip- or Deflate-compressed stream by auto-detecting the header.". So I figured that would be the "safest bet". I agree on checking for the *deflate* algorithm, so I updated the code to include the check, and a unit test, so we test gzip and deflate in separate cases.