Refactor ExtendedTracer, ExtendedSpanBuilder to reflect incubating API conventions

[jack-berg]

ExtendedTracer, ExtendedSpanBuilder break with the pattern used elsewhere for experimental APIs in that they are implemented using concrete classes instead of as extended versions of the stable interfaces.

This makes it impossible to implement behavior which depends on internal state only accessible from the SDK. Refactoring this so I can add ExtendedTracer#enabled with a response that reflects whether the Tracer's scope config is enabled.

Also adds working code examples demonstrating the usage, instead of brittle non-compiled examples in the readme.

cc @zeitlinger

[zeitlinger]

We could also consider promoting to stable now

[jkwatson]

👍🏽

[jack-berg]

We could also consider promoting to stable now

I'm supportive of that. The only thing that gives me pause is the SpanCallable, SpanRunnable interfaces. Would be preferable if we didn't introduce our own functional interfaces and could use Callable, Runnable instead. I understand that we loose type safety over the exception type, but could be worthwhile to have an API with types from standard java users are familiar with.