Fixing bugs in HTTP/2 pipeline exception handling

Motivation:

HTTP/2 codec does not properly test exception passed to
exceptionCaught() for instanceof Http2Exception (since the exception
will always be wrapped in a PipelineException), so it will never
properly handle Http2Exceptions in the pipeline.

Also if any streams are present, the connection close logic will execute
twice when a pipeline exception. This is because the exception logic
calls ctx.close() which then triggers the handleInActive() logic to
execute.  This clears all of the remaining streams and then attempts to
run the closeListener logic (which has already been run).

Modifications:

Changed exceptionCaught logic to properly extract Http2Exception from
the PipelineException.  Also added logic to the closeListener so that is
only run once.

Added a test for verifying that a pipeline exception closes the
connection.

Result:

Exception handling logic is tidied up.
@Scottmitch your description of how the http2 codec differs from traditional codecs is accurate.

Ultimately, I just want to resolve the "chicken and the egg" problem and cherry-pick this PR :).  I have a specific need for a handler/listener to have direct access to the handler for writing, so this circular dependency is very real for me.  This was previously solved with the old architecture ... we just need a way to solve it with the new layout.  There are two main ways of doing this currently:

1) Make the handler be both the listener and the writer (i.e. AbstractHttp2ConnectionHandler) and a subclass that delegates to an external listener or use by the HTTP/1 adapter layer.

2)  Subclass the handler and capture the listener events internally (admittedly an ugly hack to get around the circular dependency).

Any additional re-architecture is beyond the scope of this PR.  I think we really need to just pick something and go with it.  We can always re-factor again later if we're not happy with it.

WDYT?