RFC: Support OpenTelemetry tracer provider concept

## Overview

OpenTelemetry has the notion of a [`TracerProvider`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#tracerprovider), which is, as the name suggests, a way of obtaining multiple `Tracer`s. A `TracerProvider` is configured with a sampler, processor, exporter, etc... Each `Tracer` obtained from this provider then uses this configuration and denotes a so-called ["instrumentation scope"](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/glossary.md#instrumentation-scope):

> A logical unit of the application code with which the emitted telemetry can be associated. It is typically the developer's choice to decide what denotes a reasonable instrumentation scope. The most common approach is to use the [instrumentation library](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/glossary.md#instrumentation-library) as the scope, however, other scopes are also common, e.g. a module, a package, or a class can be chosen as the instrumentation scope.
>
> *OpenTelemetry Spec: [`InstrumentationScope`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/glossary.md#instrumentation-scope)*

A `TracerProvider` can be configured as the global one, thus making it available to instrumented libraries.

## Swift Distributed Tracing Support

This concept is similar to our `InstrumentationSystem`, but instead of bootstrapping a single "unscoped" global tracer, it bootstraps a global tracer to obtain "scoped" tracers.

I'm keen on getting your thoughts on this to decide whether we want to embrace this OpenTelemetry concept or discard it from our API.

## Alternatives considered

### Supporting `TracerProvider`s in [`swift-otel`](https://github.com/slashmo/swift-otel)

The issue with only supporting `TracerProvider`s in `swift-otel` is that instrumented libraries with built-in tracing support don't know about the implementation details of `swift-otel`, therefore making it impossible to correctly implement `TracerProvider`s in `swift-otel` only.

---

## See Also 📚

- [OpenTelemetry Spec: `TracerProvider`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#tracerprovider)
- [OpenTelemetry Spec: `InstrumentationScope`](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/glossary.md#instrumentation-scope)

Start by reading this RFC alongside the linked OpenTelemetry TracerProvider and InstrumentationScope specifications, then review the existing InstrumentationSystem API in the repository. Define whether Swift Distributed Tracing should expose the provider concept or reject it, and document the resulting API direction and rationale as the completed outcome.

Written by the indexing model from the issue text.