ALPN should allow handshake failure if no compatible protocols found

Motivation:
If there are no common protocols in the ALPN protocol exchange we still compete the handshake successfully.  This handshake should fail according to http://tools.ietf.org/html/rfc7301#section-3.2 with a status of no_application_protocol.  The specification also allows for the server to "play dumb" and not advertise that it supports ALPN in this case (see MAY clauses in http://tools.ietf.org/html/rfc7301#section-3.1)

Modifications:
-Upstream project used for ALPN (alpn-boot) does not support this.  So a PR https://github.com/jetty-project/jetty-alpn/pull/3 was submitted.
-The netty code using alpn-boot should support the new interface (return null on existing method).
-Version number of alpn-boot must be updated in pom.xml files

Result:
-Netty fails the SSL handshake if ALPN is used and there are no common protocols.
SSL JDK Mutual Authentication

Motivation:
Netty currently does not support creating SslContext objects that support mutual authentication.

Modifications:
-Modify the SslContext interface to support mutual authentication for JDK and OpenSSL
-Provide an implementation of mutual authentication for JDK
-Add unit tests to support new feature

Result:
Netty SslContext interface supports mutual authentication and JDK providers have an implementation.
Code clean-up

- Fix the inspector warnings
- Fix the infinite recursion in SslContext.newClientContext()
- Fix Javadoc errors
Add ApplicationProtocolConfig.DISABLED

Motivation:

When ALPN/NPN is disabled, a user has to instantiate a new
ApplicationProtocolConfig with meaningless parameters.

Modifications:

- Add ApplicationProtocolConfig.DISABLED, the singleton instance
- Reject the constructor calls with Protocol.NONE, which doesn't make
  much sense because a user should use DISABLED instead.

Result:

More user-friendly API when ALPN/NPN is not needed by a user.
Replace HttpHeaders.Names/Values with HttpHeaderNames/Values

Related: 4ce994dd4fe58a03fa25b0911e5b3a2079b33692

Motivation:

In 4.1, we were not able to change the type of the HTTP header name and
value constants from String to AsciiString due to backward compatibility
reasons.

Instead of breaking backward compatibility in 4.1, we introduced new
types called HttpHeaderNames and HttpHeaderValues which provides the
AsciiString version of the constants, and then deprecated
HttpHeaders.Names/Values.

We should make the same changes while deleting the deprecated classes
activaly.

Modifications:

- Remove HttpHeaders.Names/Values and RtspHeaders
- Add HttpHeaderNames/Values and RtspHeaderNames/Values
  - Make HttpHeaderValues.WEBSOCKET lowercased because it's actually
    lowercased in all WebSocket versions but the oldest one
- Do not use AsciiString.equalsIgnoreCase(CharSeq, CharSeq) if one of
  the parameters are AsciiString
  - Avoid using AsciiString.toString() repetitively
    - Change the parameter type of some methods from String to
      CharSequence

Result:

A user who upgraded from 4.0 to 4.1 first and removed the references to
the deprecated classes and methods can easily upgrade from 4.1 to 5.0.
Remove non-standard header values from HttpHeaderValues

Motivation:

x-gzip and x-deflate are not standard header values, and thus should be
removed from HttpHeaderValues, which is meant to provide the standard
values only.

Modifications:

- Remove X_DEFLATE and X_GZIP from HttpHeaderValues
- Move X_DEFLATE and X_GZIP to HttpContentDecompressor and
  DelegatingDecompressorFrameListener
  - We have slight code duplication here, but it does less harm than
    having non-standard constant.

Result:

HttpHeaderValues contains only standard header values.
Remove CollectionUtils

Motivation:

CollectionUtils has only one method and it is used only in DefaultHeaders.

Modification:

Move CollectionUtils.equals() to DefaultHeaders and make it private

Result:

One less class to expose in our public API
HTTP/2 OutboundFlowControl negative window excpetion

Motivation:
The DefaultOutboundFlowController was attempting to write frames with a negative length.  This resulted in attempting to allocate a buffer of negative size and thus an exception.

Modifications:
- Don't allow DefaultOutboundFlowController to write negative length buffers.

Result:
No more negative length writes which resulted in IllegalArgumentExceptions.
HTTP/2 to HTTP/1 non-ascii headers reset stream

Motivation:
The HTTP/2 specification indicates that when converting from HTTP/2 to HTTP/1.x and non-ascii characters are detected that an error should be thrown.

Modifications:
- The ASCII validation is already done but the exception that is raised is not properly converted to a RST_STREAM error.

Result:
- If HTTP/2 to HTTP/1.x translation layer is in use and a non-ascii header is received then a RST_STREAM frame should be sent in response.
Keeping HTTP/2 HEADERS frames in-place WRT DATA frames.

Motivation:

Currently due to flow control, HEADERS frames can be written
out-of-order WRT DATA frames.

Modifications:

When data is written, we preserve the future as the lastWriteFuture in
the outbound flow controller.  The encoder then uses the lastWriteFuture
such that headers are only written after the lastWriteFuture completes.

Result:

HEADERS/DATA write order is correctly preserved.
Closure of stream with pending frames causes GO_AWAY.

Motivation:

The current logic in DefaultHttp2OutboundFlowController for handling the
case of a stream shutdown results in a Http2Exception (not a
Http2StreamException). This results in a GO_AWAY being sent for what
really could just be a stream-specific error.

Modifications:

Modified DefaultHttp2OutboundFlowController to set a stream exception
rather than a connection-wide exception.  Also using the error code of
INTERNAL_ERROR rather than STREAM_CLOSED, since it's more appropriate
for this case.

Result:

Should not be triggering GO_AWAY when a stream closes prematurely.
HTTP Content Encoder allow EmptyLastHttpContent

Motiviation:
The HttpContentEncoder does not account for a EmptyLastHttpContent being provided as input.  This is useful in situations where the client is unable to determine if the current content chunk is the last content chunk (i.e. a proxy forwarding content when transfer encoding is chunked).

Modifications:
- HttpContentEncoder should not attempt to compress empty HttpContent objects

Result:
HttpContentEncoder supports a EmptyLastHttpContent to terminate the response.
HTTP/2 Data Compressor

Motivation:
The HTTP/2 codec currently does not provide an interface to compress data. There is an analogous case to this in the HTTP codec and it is expected to be used commonly enough that it will be beneficial to have the feature in the http2-codec.

Modifications:
- Add a class which extends DefaultHttp2ConnectionEncoder and provides hooks to an EmbeddedChannel
- Add a compressor element to the Http2Stream interface
- Update unit tests to utilize the new feature

Result:
HTTP/2 codec supports data compression.
Add generic versions of PromiseAggregator and PromiseNotifier.

Motivation:

ChannelPromiseAggregator and ChannelPromiseNotifiers only allow
consumers to work with Channels as the result type. Generic versions
of these classes allow consumers to aggregate or broadcast the results
of an asynchronous execution with other result types.

Modifications:

Add PromiseAggregator and PromiseNotifier. Add unit tests for both.
Remove code in ChannelPromiseAggregator and ChannelPromiseNotifier and
modify them to extend the new base classes.

Result:

Consumers can now aggregate or broadcast the results of an asynchronous
execution with results types other than Channel.
Minor corrections to Http2 example javadocs.

Motivation:
There are a few very minor issues in the Http2 examples javadoc and
since I don't think that these javadocs are published this is very much
optional to include.

Modifications:
Updated the @see according to [1] to avoid warning when generating
javadocs.

Result:
No warning when generating javadocs.

[1] http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/javadoc.html#@see
Make SslProvider.JDK the default provider for http2 examples using ALPN.

Motivation:
When running the http2 example no SslProvider is specified when calling
SslContext.newServerContext. This may lead to the provider being
determined depending on the availabilty of OpenSsl. But as far as I can
tell the OpenSslServerContext does not support APLN, which is the
protocol configured in the example.
This produces the following error when running the example:

Exception in thread "main" java.lang.UnsupportedOperationException:
OpenSSL provider does not support ALPN protocol
io.netty.handler.ssl.OpenSslServerContext.toNegotiator(OpenSslServerContext.java:391)
io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:117)
io.netty.handler.ssl.SslContext.newServerContext(SslContext.java:238)
io.netty.handler.ssl.SslContext.newServerContext(SslContext.java:184)
io.netty.handler.ssl.SslContext.newServerContext(SslContext.java:124)
io.netty.example.http2.server.Http2Server.main(Http2Server.java:51)

Modifications:
Force SslProvider.JDK when creating the SslContext since the
example is using APLN.

Result:
There is no longer an error if OpenSsl is supported on the platform in
use.
Merge https://github.com/netty/netty