Rethink INP span traceId assignent

### Problem Statement

Today, we assign the currently active traceId to an INP standalone span when creating it. However, we backdate the INP span's startTime to the time of the actual interaction and also assign the active route span name of said interaction. This leads to a very weird trace view experience, where the INP span happens way before the actual trace root span (e.g. a navigation span).

### Solution Brainstorm

We should rethink the traceId assignment to not only assign the root span name that was active at interaction time but also that span's traceId. This might however require us to do some virtual trace continuation shenanigans or add the possibility to explicitly pass in a traceId when starting a span. Things to consider:

- INP emissions are not tied to times where a parent span exists. This is also a problem in the current implementation, where for such cases we fall back to the currently active route name
- we need to ensure that retroactively adding the INP span to an "old" trace does not mess with previous trace linking