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.
Why are you using `zlib.unzip()` instead of `zlib.gunzip()`?

I feel like there is a disconnect between the header you specified (`Accept-Encoding: gzip, deflate`) and the condition here. I think that there should be a check for `deflate` somewhere and that the `zlib.inflate()` and `zlib.gunzip()` methods should be used.

Unfortunately, this is mostly just a guess *(based on naming)* because the node docs are pretty pitiful for those methods.