Add tracing support to gRPC impls by sniffing HTTP/2 frames on underlying TCP socket

[jhump]

This adds a new tracing capability -- to wrap a net.Conn that represents an HTTP/2 connection and examine all of the HTTP/2 traffic to assemble a trace. This is used to instrument a gRPC client and server to support tracing, since they include their own HTTP/2 implementation instead of using net/http.

The only testing I've done is to set breakpoints in an IDE to make sure the trace events were flowing. I'll probably add some very basic tests of the tracing (both the new HTTP/2 stuff and the existing net/http stuff) and push them to this PR, just so we have more comfort that this stuff doesn't stays functional and doesn't regress since it is admittedly pretty complicated and not otherwise covered by tests.

This will resolve #817.

[jhump]

@smaye81, I just added some tests for the tracing stuff, and they caught a few things. Most of what they caught was non-deterministic ordering of events (which could even lead to events being dropped).

So this changes some of the locking in several places to make larger chunks of logic atomic -- for example the handleFrame method of the tracing net.Conn would acquire the lock, query a map, unlock, and then possibly have to acquire the lock again for a second step. Now everything is done atomically with a single lock acquisition. This was also true in the trace builder's add method -- it could do everything under lock and then, when it optionally called build from a defer function, it would re-acquire the lock. It's been restructured to only need a single lock acquisition now.

The new test is a bit of a beast, but it verifies all of the ways to instrument a client and server, both with middleware or with wrapping an HTTP/2 net.Conn socket.

[smaye81]

lgmt, ship it!