…#47428)

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

<!-- All pull requests REQUIRE a test plan:
https://docs.sourcegraph.com/dev/background-information/testing_principles
-->

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

---------

Co-authored-by: Jean-Hadrien Chabran <jh@chabran.fr>