Refactor LzfDecoder to use proper state machine

Motivation:

Make it much more readable code.

Modifications:

- Added states of decompression.
- Refactored decode(...) method to use this states.

Result:

Much more readable decoder which looks like other compression decoders.
Allowing negative keys in IntObjectHashMap.

Motivation:

IntObjectHashMap throws an exception when using negative values for
keys.

Modifications:

Changed hashIndex() to normalize the index if the mod operation returns
a negative number.

Result:

IntObjectHashMap supports negative key values.
Optimize IntObjectHashMap handling of negative keys.

Motivation:

The hashIndex method currently uses a conditional to handle negative
keys. This could be done without a conditional to slightly improve
performance.

Modifications:

Modified hashIndex() to avoid using a conditional.

Result:

Slight performance improvement to hashIndex().
Slight performance improvement to IntObjectHashMap.hashIndex()

Motivation:

Using a needless local copy of keys.length.

Modifications:

Using keys.length explicitly everywhere.

Result:

Slight performance improvement of hashIndex.
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 implementaiton 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.