BatchSpanProcessor accesses deleted resources after tracer destruction

[benlandrum]

Describe your environment
Using a version after v1.0.0-rc2, including recent fixes to scopes and StartSpan.

Steps to reproduce
Destroy a tracer provider connected to a batch span processor while it is processing spans.

What is the expected behavior?
Even on tracer provider destruction, which could happen if a user wants to change the tracing configuration, the batch span processor will emit spans with resources intact.

What is the actual behavior?
Resource attributes are absent from spans emitted by the batch span processor on tracer provider destruction.

Additional context
I've observed the following sequence of events.

1. BatchSpanProcessor::OnEnd adds the span to its circular buffer. The resource has the expected attributes.
2. BatchSpanProcessor::OnEnd does not notify the worker thread.
3. The tracer's destructor gets called, due to intentional destruction of the global tracer provider.
4. That tracer's resource destructor gets called (due to tracer destruction).
5. BatchSpanProcessor::DrainQueue gets called.
6. BatchSpanProcessor::Export consumes the circular buffer. The resource (still at the same address) has no attributes.

Perhaps the destruction order needs to be adjusted, or recordables should not store bare pointers to resources.

See the Slack discussion for a similar problem occurring.

[benlandrum]

One possibility is to rearrange the members of TracerContext, constructing the resource_ before the processor_ (and commenting on order dependence). This way, the the processor would get destroyed before the resource.