Expose static RuntimeContext storage for lifecycle management #1211

Before opening a feature request against this repo, consider whether the feature should/could be implemented in the other OpenTelemetry client libraries. If so, please open an issue on opentelemetry-specification first.

Is your feature request related to a problem?
I am working on the Apache Arrow project and this is related to an issue we have: ARROW-15604

The problem is that Arrow has a thread pool stored in its own static state. We create spans in tasks that run on that thread pool. At shutdown, there is no way to control which static state gets destroyed first. Usually it is OpenTelemetry's state that is destroyed first because the thread pool tries to wait until its worker threads have finished. Those worker threads are usually finishing up tasks and, at the end, destroy a scope. The scope's destructor attempts to access the static runtime context storage but it has already been destroyed.

We can work around this by initializing the runtime context storage ourselves and using opentelemetry::context::RuntimeContext::SetRuntimeContextStorage but this is only a workaround because we are a library and not an application so we risk overriding the user's runtime context storage. Instead we'd like to be able to make a copy of OTel's shared pointer so that we can keep it alive until our threads finish.

Describe the solution you'd like
If the method opentelemetry::context::RuntimeContext::GetRuntimeContextStorage() were public that would solve our problem.

Describe alternatives you've considered
I think we're open to any alternatives that we can use to extend the lifetime of the runtime context storage.

Additional context
I've created a simple reproduction of this issue here: https://github.com/westonpace/otel-storage-accessor-repr