Get rid of dependencies to vendor specific tracer implementations

[thegreystone]

Look into java-api-extensions. We will likely need opentracing-contrib/java-api-extensions#18 fixed for the thread local scope events.

[thegreystone]

Thinking a bit further, we will probably want to balance the opentracing-contrib/java-api-extensions dependency against the fact that we have very little code for the actual wrappers, and we'd have another dependency to manage. Not to mention be limited to whatever the API expose, and have less room for optimizations.

The limiting factor here is what the span exposes. Operation name we can propagate ourselves. Will add another issue for that.

[thegreystone]

See discussion at opentracing/opentracing-java#314. As soon as it is resolved, and we have all we need, all vendor specific tracer-stuff can be removed (ContextExtractor and friends).

[thegreystone]

The opentracing-0.32.0 branch currently shows what it would look like. Sadly, we'd lose parentId as the proposal currently stands.

[thegreystone]

The thing we would lose is reconstructing the DAG directly from recording data. It would be sexy to have it (and render it), but we could, perhaps, survive.

[thegreystone]

#14