Added an option to use websockets without masking

Motivation:

The requirement for the masking of frames and for checks of correct
masking in the websocket specifiation have a large impact on performance.
While it is mandatory for browsers to use masking there are other
applications (like IPC protocols) that want to user websocket framing and proxy-traversing
characteristics without the overhead of masking. The websocket standard
also mentions that the requirement for mask verification on server side
might be dropped in future.

Modifications:

Added an optional parameter allowMaskMismatch for the websocket decoder
that allows a server to also accept unmasked frames (and clients to accept
masked frames).
Allowed to set this option through the websocket handshaker
constructors as well as the websocket client and server handlers.
The public API for existing components doesn't change, it will be
forwarded to functions which implicetly set masking as required in the
specification.
For websocket clients an additional parameter is added that allows to
disable the masking of frames that are sent by the client.

Result:

This update gives netty users the ability to create and use completely
unmasked websocket connections in addition to the normal masked channels
that the standard describes.
Minor update to Http2LifecycleManager#closeLocalSide javadoc

Modifications:
Changed "remote" to "local" in javadoc for closeLocalSide.
HTTP/2 Send GOAWAY if no more stream ids

Motivation:
If the http2 encoder has exhausted all available stream IDs a GOAWAY frame is not sent. Once the encoder detects the a new stream ID has rolled over past the last stream ID a GOAWAY should be sent as recommended in section [5.1.1](https://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-5.1.1).

Modifications:
-This condition is already detected but it just needs to result in a GOAWAY being sent.
-Add a subclass of Http2Exception so the encoder can detect this special case.
-Add a unit test which checks that the GOAWAY is sent/received.

Result:
Encoder attempting to use the first 'rolled over' stream id results in a GOAWAY being sent.
SslHandler wrap memory leak

Motivation:
The SslHandler wrap method requires that a direct buffer be passed to the SSLEngine.wrap() call. If the ByteBuf parameter does not have an underlying direct buffer then one is allocated in this method, but it is not released.

Modifications:
- Release the direct ByteBuffer only accessible in the scope of SslHandler.wrap

Result:
Memory leak in SslHandler.wrap is fixed.
SslHander wrap conditional direct buffer allocation

Motivation:
The SslHandler currently forces the use of a direct buffer for the input to the SSLEngine.wrap(..) operation. This allocation may not always be desired and should be conditionally done.

Modifications:
- Use the pre-existing wantsDirectBuffer variable as the condition to do the conversion.

Result:
- An allocation of a direct byte buffer and a copy of data is now not required for every SslHandler wrap operation.
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.