[v9] Rethink `spanId` on `propagationContext`

[mydea]

Today, we have a propagation context on every span that receives a random traceId and spanId (unless it is continued from an external service). We use these IDs to populate trace headers for further propagation.

A scope always has a propagation context, and you can't really tell if this is a "random" one or one that is continued from somewhere...

We should maybe reconsider this, as today this leads to a bunch of confusion, and may lead to cases where we send a parent_span_id that does not exist (because it comes from the propagationContext, not an actual span).

[mydea]

More concretely, I propose the following changes:

1. Make the propagation context optional on the scope.
2. Conceptionally the propagation context should be owned by the isolation scope, not the current scope - we will only set it on the isolation scope, so unless a user specifically overwrites this on the current scope, we'll always use the isolation scope one.
3. The isolation scope will always have a propagation context, so we ensure TWP still works.
4. Update the type of propagation context like so (naming TBD but you get the idea):

interface LocalPropagationContext {
  traceId: string;
  virtualSpanId: string;
}

interface ContinuedPropagationContext {
  traceId: string;
  sampled?: boolean;
  parentSpanId: string;
  dsc?: Partial<DynamicSamplingContext>
}

interface Scope {
  // undefined: this is probably not an isolation scope. should never be undefined on an isolation scope
  // LocalPropagationContext: TWP mode (else this is ignored anyhow), default
  // ContinuedPropagationContext: Incoming trace is continued
  propagationContext: undefined | LocalPropagationContext | ContinuedPropagationContext;
}

This way, you can always differentiate what state you are in, if you are using a "local/virtual" propatation context (by checking if virtualSpanId exists), or if you are continuing a trace. This gets rid of the somewhat confusing spanId property.

[lforst]

Our current view on this topic is that span ID on the prop context can be safely removed.

Architecturally we need to ensure that performance and the prop context are completely decoupled.

Performance data may feed into the prop context but not the other way around. The prop context was designed for tracing without performance.

As part of this task we need to go through the entire SDK and make sure that the any performance tracking mechanisms don't read from the propagation context.