Improve Robustness of interaction spans

### Description

Our browser SDKs offer an experimental feature in `browserTracingIntegration` - interaction ~transactions~ spans.

While the idea sounds great, in reality, they're currently a bit problematic and not yet robust enough to enable them by default:

### Problems/Symptoms

1. Every single click or interaction starts a span, regardless of if the click actually caused any event on the page or if it was a dead click
2. Even if the interaction was not a dead click, chances are high that the resulting effects of the click are not worth sending the span (tree). For instance, if a click onto a button displays an element that was previously hidden, there will be no resource span, no http request span or anything else that our auto instrumentation would catch.
3. Naming is hard. At the moment, the interaction root idle span gets the route name but a `ui.interaction` op. This is because we can't use the selector of the clicked element as a span name because it's high cardinality as, depending on the application, it can change very frequently.
4. Currently, due to the v8 tracing model in the browser, interaction spans are added to the same trace as the previous `pageload` or `navigation` span.
5. Interaction root spans are idle spans because there's no clear ending point we can use to deterministically end the span.

### Solution Brainstorming

1. We can try to add some simple heuristics around if the click was made onto an interactive element or not. This should be fairly easily testable and we could even create a user-overrideable API around selectors that should be deemed interactive.
- Alternatively or in combination, we could let users decide which elements should even start an interaction span. For example by letting them specify a `data-sentry-trace` attribute on the respective html element.
2. We can simply decide to not send an interaction span (tree) if there are no spans other than `ui.interaction.*` spans in the tree. Realistically, today, with our auto instrumentation, this would mean that we'd only send interaction spans if
- a fetch/xhr request was made
- users enabled component tracking in a framework SDK that supports the feature and the interaction causes mounts or updates of components
- users manually instrumented operations triggered by the interaction
3. I think this is fine as it is but happy to hear different opinions on the matter
4. I also think that this is fine, assuming we continue to be okay with long-running traces. The alternative requires changes to the tracing model in the browser which we can and should think about but not solely for the purpose of interaction spans.
5. While no-one really is a fan of idle spans, I think there's no alternative to having them in the browser. I think this is also fine and just something, we need to deal with product-side (i.e. not give the duration of the root span too much meaning).