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 2 of your comments. I added a unit test, so we can test both gzip and deflate algorithms in separate cases (your comment was about setting content-encoding to gzip and using deflate to compress the data).

Your other comment was about testing it with a larger payload, so I created a small loop to send a lot of text, they are actually small json objects serialized into a string. Do you think it does the job?