Upgrading to HTTP/2 draft 14 HTTP/1.x message flow

Motivation:

HTTP/2 draft 14 came out a couple of weeks ago and we need to keep up
with the spec.

Modifications:

-Allow informational type messages to be sent up the pipeline immediatley.
-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.
This brings up a few interesting points w.r.t to queuing and HTTP/1.x:

1. I originally based the HTTP/1.x translation interface off of `SpdyHttpDecoder` and was outputting FullHttpMessage objects.  I then changed this to avoid the excessive queuing and memory this may have required and instead sent HttpObject elements directly up the pipeline.  I now realize this was a mistake.  If HttpObjects are passed up the pipeline there is no way for the ChannelHandler to know which HttpObject is associated with which stream (this is the point of HTTP/2 having a frame structure which includes a stream id).
2. Having no queuing and directly firing events up the pipeline means that priority can not be accurately represented in HTTP/1.x headers.  This is because the priority change events can happen while a stream is open and the headers have already been sent.

So as a result of these reflections I think I need to make the following changes:

1. I need to bring the queuing back to support outputting only objects of type FullHttpMessage.  This may be a bit awkward (or require re-factoring) because I need to support the functionality of `HttpContentDecoder` to be able to decode DATA.
2. Bringing the queuing back and hanging on to the FullHttpMessage will allow processing of HTTP/2 priority events to be correctly reflected in HTTP/1.x headers.  This is because the FullHttpMessage will not be sent up the pipeline until the end of stream is encountered.  Granted queuing up priority events and dispatching them at the end of the message may defeat the purpose a bit, but that is the nature of the HTTP/1.x message flow and the reason HTTP/2 was invented.

@nmittler - Does this make sense?