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.
As recommended earlier, I think this would be better implemented using the `zlib.createGunzip()` and `zlib.createInflate()` methods to create streams that would eliminate this juggling of buffers.