feat: add initial support for tracing

[enocom]

This is what the Dial trace looks like:

This is what the Refresh trace looks like:

Some of the trace code is borrowed from here. Note: the code there uses context lookups to find the associated span, which has a performance penalty. This code uses a closure so callers don't need to keep track of the span.

Related to #15.

It's probably worth discussing how we want to name our traces, too, because they'll become part of the public API in effect. As a result, I've not used concrete type names for internal tracing, just so we can move the internals around without issue in the future.

[kurtisvg]

One thing that aren't clear to me:

Are these exported all the time? What if someone wants to export somewhere specific (aka not Cloud Logging)?

[enocom]

Are these exported all the time? What if someone wants to export somewhere specific (aka not Cloud Logging)?

The tracing is enabled only if a client has used OpenCensus to register an exporter. With no exporter registered, these traces become no-ops. Also, the client can choose their exporter as the tracing here is agnostic.

[kurtisvg]

Are these exported all the time? What if someone wants to export somewhere specific (aka not Cloud Logging)?

The tracing is enabled only if a client has used OpenCensus to register an exporter. With no exporter registered, these traces become no-ops. Also, the client can choose their exporter as the tracing here is agnostic.

Let's include instructions in the README for this.

[enocom]

I've added the instance name as an attribute to the parent span in both cases:

The naming scheme follows what I'm seeing from other labels, e.g., /http/user_agent, /http/host etc.