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.
@nmittler - Unless I'm misunderstanding I'm not sure I like that :).  I would like to avoid if possible the model of `AbstractHttp2ConnectionHandler` where there was an intermediate listener layer.  This listener layer seems unnecessary in some situations as we can just directly dispatch to the listener.  Then it follows from this the concept of `DelegatingHttp2ConnectionHandler` may also be unnecessary because we don't need to delegate if we are already directly dispatching.

I'm not suggestion you don't know the following but I want to dump my mental model of a "traditional" codec vs the http2 codec to make sure I'm on the right track.  A "traditional" codec would call `channel.write(...)` with some object and an encoder in the pipeline would be designed to transform that type into bytes some how.  We are in a different situation where the coupling is a bit higher because we are not basing our send/receive off of object types but instead function calls/signatures.  So at some level the if the receive side needs to send the receive side needs to have a reference to a send interface of some kind.

So your immediate concerns are not necessarily with this coupling but the specific implementation of `Http2OutboundConnectionAdapter` and `Http2FrameListener ` relative to their current responsibilities and extension points?  I'm not trying to put words in your mouth but instead trying to understand the root cause because I think your eluding to a creating a better way to structure the interfaces and so the coupling is cleaner/improved?