Adding support for HTTP/2 binary headers

Motivation:

The HTTP/2 spec does not restrict headers to being String. The current
implementation of the HTTP/2 codec uses Strings as header keys and
values. We should change this so that header keys and values allow
binary values.

Modifications:

Introduced ByteString from okio (with a few minor mods). Added new
BinaryHeaders interface and made Http2Headers extend it. Various changes
throughout the HTTP/2 codec to use the new interface.

Result:

HTTP/2 codec no longer requires string headers.
@nmittler - I think I like your suggestion...A few follow up questions:
-1. Just to clarify...this step is implying to change all HTTP and HTTP2 predefined headers to be of type `BinaryHeaders` (change `HttpHeaders` from using `AsciiString` to `BinaryHeaders`, and change `HttpHeaders` to extend from `BinaryHeaders`)?  I think this is a good thing (from http/2 perspective) but do we need to be concerned with supporting the existing `CharSequence` interface methods (i.e `String get(CharSequence name)` and all other methods with `CharSequence name`)?

-4. Just to clarify...http2 headers are "case-insensitive" in that they are always forced to lower case.  Where HTTP headers are "case-insensitive" in that the original case is preserved but comparisons are done in a case in case-insensitive way.  Is this correct?  So if we wanted we could define all the predefined headers as lower case and then HTTP/2 would not need to worry about case at all, only HTTP would need to worry about "case-insensitive" comparison (which makes sense because the HTTP spec doesn't clarify in this situation which the HTTP/2 spec does).

-6. Just to clarify...this is assuming in the construction of the pipeline (or http/2 codec objects) we will be supplying a `BinaryHeadersFactory` to interpret the bytes supplied by twitter hpack?  The goal of these factories would be to use the "trusted" zero-copy constructor of `ByteString`