Reconsider use of singletons about opentelemetry-go

[jmacd]

There is an outstanding RFC on this topic.
https://github.com/open-telemetry/oteps/blob/master/text/0005-global-init.md

This issue is sufficiently complicated that I would invite you to discuss them in the OpenTelemetry-Go SIG at our Thursday meeting (info: https://github.com/open-telemetry/community).

I am familiar with the arguments against package-global state, but we have a conflicting requirement in OTel to support "automatic" instrumentation, which supposes that a library can begin to use instrumentation without explicit dependency injection.

I've argued that support for a globally-registered SDK that is explicitly set once by the application is not the same as package-global state. For one thing, it's not mutable--it's set once at the right time during startup. If you'll ignore the testing use-case, which can be addressed separately.

We agree, too, that you are free to use explicit dependencies and not use the global state. It's permissible to run more than one SDK concurrently, but one of them may be installed as the global default.

We've heard proposals that we use a context lookup instead of a global, which would allow callers to override the default SDK based on context, but if someone uses context.Background() we think there should be a default installed globally.

[rghetia]

stale issue.