This PR changes the performance handling of the node-experimental package fundamentally, aligning it even more with the OpenTelemetry model.

### Tasks
- [x] Store breadcrumbs as `TimedEvent` on otel spans
- [x] Update `startSpan` / `startInactiveSpan` to create & expose OTEL spans (instead of sentry spans)
- [x] Update span processing to avoid global map & use exporter
- [x] Add unit tests
- [x] Add E2E test

The core changes are:

• startSpan / startInactiveSpan create Otel spans now, not Sentry Spans/Transactions
• Generally, Sentry spans/transactions should be completely gone, from a users POV
• Splits the functionality that was previously in the SpanProcessor into a new SpanProcessor + SpanExporter
• Ditches the global map for state in favor of some WeakMaps, which means we do not need to clean our references up manually anymore etc.
• Breadcrumbs are stored as events on the otel spans

How does transaction/span creation work now

In the old model, we would start transactions/spans in the span processor onStart and onEnd hook. This required us to keep track of the parent Sentry span, as we need it to call parentSpan.startSpan() in onStart. Since it can be tricky to know when a span is not needed anymore as a parent etc, this made garbage collection harder and messier, and also required us to still sprinkle Sentry spans/transactions everywhere through our code.

In the new model, only minimal processing is done in the span processor, and importantly, we do not create any Sentry spans yet. We store some additional data we need later in a WeakMap associated to the (Otel) span.

Then we leverage the underlying BatchSpanProcessor from OTEL, which collects spans together and sends them for processing to a SpanExporter. So only finished spans end up in our span processor. Our custom span exporter does the following:

• Builds a tree hierarchy of the spans
• Picks the root spans that are found, and builds transactions from there - adding children down the tree
• Every span/transaction is immediately finished (with the correct end time) and then sent
• Note that we store the current scope when the transaction was created and apply this scope.

For now I copied most of the stuff from opentelemetry-node over, eventually we can merge most of this together probably and export the parts from opentelemetry-node.

How do breadcrumbs work

We now pick all events added to spans and add them as breadcrumbs.
For this, we walk up the tree of spans up to the root and collect all breadcrumbs together. We use a special JSON field for now to actually store the breadcrumbs data (TODO: Maybe there is a better way to do this...).
When we add a breadcrumb, we actually always add it to the root span for now, not the active span. The reason is that this works better with our mental model of breadcrumbs, where anything that happens in this root span is relevant. But we'll also pick up any other events added by otel instrumentation along the way.

Open questions

• Should we apply the scope when a span is started, or when it is finished? OTEL uses the context when it was started, and the model makes this easier to implement, but if we prefer we can probably also pick the current context/scope in onEnd. But not 100% sure how this would work with parallel spans, needs to be tested I guess.