ref(tracing): Split `@sentry/tracing` into runtime specific packages

[timfish]

Problem Statement

After some discussions around supporting newer JavaScript runtimes (#5611) @lforst pointed out the first thing that needs tackling is @sentry/tracing!

This package currently contains:

• Runtime agnostic code used to add transaction support to the hub
• Browser specific instrumentation code
• Node.js specific instrumentation code

Goal: Remove the tracing package, move stuff into core/browser/node

Solution Brainstorm

It looks like the runtime agnostic code can safely be moved to @sentry/core without affecting bundle sizes since if it goes unused it gets tree-shaken.

The runtime specific code could be moved into package exports under the specific runtime, ie. @sentry/browser/tracing and @sentry/node/tracing. We've been using this in the Electron SDK for a while to keep bundlers happy with the two different contexts we run in. We can't export the tracing code at the root of the packages since importing tracing has side-effects!

I haven't marked this issue as Breaking yet because I think it would be possible to move this code while keeping @sentry/tracing as a stub that would simply re-export the moved code. @sentry/tracing would have to depend on both @sentry/browser and @sentry/node so I'm not sure how viable this is yet or if it's worth that extra step 🤔

### Tasks
- [ ] https://github.com/getsentry/sentry-javascript/issues/7091
- [ ] https://github.com/getsentry/sentry-javascript/pull/7345
- [ ] https://github.com/getsentry/sentry-javascript/issues/7342
- [ ] https://github.com/getsentry/sentry-javascript/issues/7346
- [ ] https://github.com/getsentry/sentry-javascript/issues/7340

### Cleanup
- [ ] https://github.com/getsentry/sentry-docs/issues/6518
- [ ] https://github.com/getsentry/sentry-javascript/issues/7586

[lforst]

Continuing the thread from #5611 (comment):

Would we want to add all the hub extensions by default too?

I think so. Ideally, we wouldn't need hub extensions anymore since it's all already there.

We wouldn't want to run _autoloadDatabaseIntegrations in the Electron SDK because it hits app startup time significantly!

We had an internal discussion about this some time ago and we would like to turn off auto-discovery by default for the next major because of the startup time.

[timfish]

If we move the existing runtime agnostic code over to @sentry/core without any significant changes and simply export the existing code there is no change to browser bundle size since it's just a load of isolated functions.

I still need to do some experimentation to see how much it adds if the code is fully integrated to the hub without extensions. I would guess this could add 5-10kB since the code ends up in the Hub class where tree shaking can't works its magic.

[timfish]

I did the experimenting and moved tracing into @sentry/core and moved the code into Hub (removing hub extensions) and it adds roughly 7kB to the minified, uncompressed browser bundle (bundle.min.js).

[timfish]

This PR on my fork shows how the runtime agnostic code from @sentry/tracing can be moved to @sentry/core without impacting bundle size. This is possible because it retains the use of hub extensions and the tracing code is not referenced by @sentry/core so it can be tree-shaken.