CorsHandler should release HttpRequest after processing preflight/error.

Motivation:
Currently, when the CorsHandler processes a preflight request, or
respondes with an 403 Forbidden using the short-curcuit option, the
HttpRequest is not released which leads to a buffer leak.

Modifications:
Releasing the HttpRequest when done processing a preflight request or
responding with an 403.

Result:
Using the CorsHandler will not cause buffer leaks.
Handle an empty ByteBuf specially in HttpObjectEncoder

Related: #2983

Motivation:

It is a well known idiom to write an empty buffer and add a listener to
its future to close a channel when the last byte has been written out:

  ChannelFuture f = channel.writeAndFlush(Unpooled.EMPTY_BUFFER);
  f.addListener(ChannelFutureListener.CLOSE);

When HttpObjectEncoder is in the pipeline, this still works, but it
silently raises an IllegalStateException, because HttpObjectEncoder does
not allow writing a ByteBuf when it is expecting an HttpMessage.

Modifications:

- Handle an empty ByteBuf specially in HttpObjectEncoder, so that
  writing an empty buffer does not fail even if the pipeline contains an
  HttpObjectEncoder
- Add a test

Result:

An exception is not triggered anymore by HttpObjectEncoder, when a user
attempts to write an empty buffer.
Overall clean-up on Headers and its subtypes

Motivation:

- There are still various inspector warnings to fix.
- ValueConverter.convert() methods need to end with the type name like
  other methods in Headers, such as setInt() and addInt(), for more
  consistency

Modifications:

- Fix all inspector warnings
- Rename ValueConverter.convert() to convert<type>()

Result:

- Cleaner code
- Consistency
Headers Cleanup

Motiviation:
Some of the contains method signatures did not include the correct type of parameters for the method names.  Also these same methods were not using the correct conversion methods but instead the generic object conversion methods.

Modifications
-Correct the parameter types of the contains methods to match the method name
-Correct the implementation of these methods to use the correct conversion methods

Result:
Headers contains signatures are more correct and correct conversion methods are used.
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.
Added an additional layer of interface to support configuration application negotiation in an SSLEngine agnostic way.