Feature/simplify iconnection

This is still a work in progress but resembles a second refactor pass on `IConnection` after @icanhasjonas excellent feedback on #537 and earlier by @synhershko on #522 

* `IConnection` now only returns `ElasticsearchResponse<Stream>`
* `IConnection` no longer in charged of deserialization, this is pushed back to `Transport` which is the coordinator between `IConnectionPool` and `IConnection` and already did the serialization.
* `<T>` no longer leaks throughout all the components involved just to be able to deserialize in the deepest call in the stack. 
* `IConnection` no longer in charge of shortcircuiting for `<string>` `<byte[]>` or ignoring the stream completely for `<VoidResponse>`. A connection is now only in charge of returning a response stream and settings connection status data on the `ElasticsearchResponse<Stream>`, it should not know more of the internals.
* As a result you can now do `client.Call<Stream>()`  and do as you please with it, you're on your own (but please Dispose() it!)
* If you do not specify a `Stream` return type Elasticsearch.Net still takes ownership of the Stream and disposes it properly.
* `ElasticsearchResponse<T>` had an `.Error` property that hold some information and caught some exceptions. This is gone now. If a request succeeds to the point where we have a status code Elasticsearch.net will never throw.It will still expose the original exception (ie WebException) on `.OriginalException` any other exception will be rethrown (possibly caught again when an IConnectionPool is in place which will rethrow in a wrapped MaxRetryException when all nodes are tried). 

Still todo:

* Move `Ping()`and `Sniff()` from `IConnection`
* `ElasticsearchResponse<T>` can now also return very interesting metric data (start time, time to first byte, time to last byte, (de)serialization time), will wait to explore that post alpha release.