Address issue of user accidentally replacing global provider

[aabmass]

@justin0mcateer was having issues with the global TracerProvider's config not being the same across modules. It turned out to be an accidental issue with the order of the OT api calls causing the provider to be overwritten:

### a.py
# expecting this to run first
trace.set_tracer_provider(TracerProvider())
# ... setup provider
tracer = trace.get_tracer(__name__)

### b.py
# but somehow this actually runs first
tracer = trace.get_tracer(__name__)

In this case, b.py runs first and the global TracerProvider gets set implicitly. b.py's tracer was made using this default global provider.

Then, a.py runs and overwrites the current global provider. Now modules a and b have tracers from different providers with different configs! b's tracer never had a span processor set up and never gets exported!

• Is there a use case where anyone would actually want to explicitly or implicitly call set_tracer_provider() more than once?
• Can OT raise an exception or at least warn if this happens? Seems easy to accidentally do since its hard to tell the order modules execute in.
• @lzchen said

  make this as part of our "easy instrumentation" story, or at least make or documentation more beginner friendly

• same goes for MeterProvider

[codeboten]

Let's add a warning if the TracerProvider is being overriden as a starting point. We could do more with global configuration.

[codeboten]

This is done for now.