Properly expose errors/exceptions

[lucasdicioccio]

It's about time we start exposing errors and exception to API users. The new dispatch mechanism allows to have fewer entry points, which makes the exception handling tracktable.

There are two broad types of errors we may want to catch and expose differently:

• connection errors (e.g., dead endpoint) and goaways
• individual stream resets

Currently the design was mostly ad-hoc, with a mix of HTTP2 errors and uncaught exeptions.

[lucasdicioccio]

I've added a schema of the current threading+error propagation model, showing a risk of leaking low-level asyncs if a remote/the kernel does not close TCP and no-one called an explicit close on the RawConnection object.

https://docs.google.com/presentation/d/1WxP7HkTHy7Rr8sA-9NydD5jRcWbFffW2yM4Pv61OCfI/edit?usp=sharing

The schema doesn't go in some level of detail (e.g., using race around the IncomingLoop to handle cancellation gracefully so that the 'pollSTM' error does not bubble up on a client-initiated close -- cf. #56 .)

[lucasdicioccio]

The branch https://github.com/lucasdicioccio/http2-client/tree/stop-polling-on-eof is already likely adding an ExceptT layer to collect exceptions, currently hiding everything out of the existing user-facing APIs.

[lucasdicioccio]

67 Has done much of the basics needed for this.

More work is required for synchronized error handling across threads (for now it's unclear who-gets-what-errors on an exception and, as far as I can tell, users should carefully link asyncs to be double safe).