Changing HTTP/2 inbound flow control to use Http2FrameWriter

Motivation:

This is just some general cleanup to get rid of the FrameWriter inner
interface withing Http2InboundFlowController.  It's not necessary since
the flow controller can just use the Http2FrameWriter to send
WINDOW_UPDATE frames.

Modifications:

Updated DefaultHttp2InboundFlowController to use Http2FrameWriter.

Result:

The inbound flow control code is somewhat less smelly :).
HTTP/2 draft 14 HTTP message flow
Motivation:

HTTP/2 draft 14 came out a couple of weeks ago and we need to keep up
with the spec.

Modifications:
-Revert back to dispatching FullHttpMessage objects instead of individual HttpObjects
-Corrections to HttpObject comparitors to support test cases
-New test cases to support sending headers immediatley
-Bug fixes cleaned up to ensure the message flow is terminated properly

Result:
Netty HTTP/2 to HTTP/1.x translation layer will support the HTTP/2 draft message flow.
Add io.netty.noJdkZlibEncoder system property

Related issue: #2821

Motivation:

There's no way for a user to change the default ZlibEncoder
implementation.

It is already possible to change the default ZlibDecoder implementation.

Modification:

Add a new system property 'io.netty.noJdkZlibEncoder'.

Result:

A user can disable JDK ZlibEncoder, just like he or she can disable JDK
ZlibDecoder.
Check noJdkZlibEncoder before comparing other parameters

.. for consistency
Custom EventLoop scheduling and EventLoop metrics

Motivation:

Currently Channels are assigned to EventLoops by a round-robin like algorithm: EventLoops are assigned sequentially and begin again at the start in a circular manner. This approach may not always be ideal, especially when an application handles different types of connections (e.g. long-living and short-living).

Modifications:

Introduce two new interfaces: EventLoopScheduler and EventLoopMetrics. The EventLoopScheduler interface allows a user to provide his own implementation of EventLoopGroup.next(). The default implementation remains round-robin. The (Nio|Epoll)EventLoops now support to collect information about them. This is done via the EventLoopMetrics interface. This information can also be used by an EventLoopScheduler implementation to influence scheduling.

Result:

1) Users can plug in their own algorithms into NioEventLoopGroup and EpollEventLoopGroup. 2) Users can gather information from EventLoops and use the information in their custom EventLoopScheduler implementations.