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 Perhaps you're right, although my intention was to try to make as few changes to the code as possible, and the buffer juggling was already there, it was just hidden by the use of the '**+**' operator to concatenate the chunks of the response, that were assumed to be text and not binary data. Do you consider this is unacceptable as it is?