The new architecture of internal/tracer:

1. Creates a TracerProvider immediately. This provider is preconfigured with service metadata, but does not have a SpanProcessor.
2. Creates an OpenTracing bridge using TracerProvider, such that we have an OpenTracing Tracer and an OpenTelemetry TracerProvider that bridges the two APIs. We register both as global defaults.
3. On site config initialization, we register a new SpanProcessor onto the global TracerProvider.
4. From this point on, site config updates:
   a. Create a new SpanProcessor based on site config
   b. Register the new SpanProcessor, which starts processing
   c. Remove the previous SpanProcessor, which flushes it and shuts it down as well

Previously, we mimicked the old opentracing setup where we swapped the global tracer, using a similar approach in OpenTelemetry to set up the global TracerProvider. In OpenTelemetry, registering and unregistering SpanProcessors is the correct way to do this it seems - the swapping approach causes configuration propagation issues such as XSAM/otelsql#115 (allowing us to revert back to upstream: https://github.com/sourcegraph/sourcegraph/pull/47429) and possibly https://github.com/sourcegraph/sourcegraph/issues/42515 . This correct approach was pointed out in XSAM/otelsql#115 (comment), and makes the setup easier to reason with:

• the previously swappable tracers now no longer need to have a locked underlying implementation, they just add logging now
• we don't need to update 2 implementations, we make the update at a lower level so that both ends of the OT/OTel bridge are updated
• debug mode is managed through a mutable atomic bool, instead of through recreating entire tracers

Test plan

Unit tests assert that span processor updates are propagated. Exporter setup is functionally unchanged