feat(sveltekit): Add performance monitoring to Sveltekit server handle

[AbhiPrasad]

ref #7526

In this PR we start tracking the performance of the SvelteKit server-side routes via the handle function.

// src/hooks.server.ts
import { sentryHandle } from '@sentry/sveltekit';

export const handle = sentryHandle;

// Optionally use the sequence function to add additional handlers.
// export const handle = sequence(sentryHandle, yourCustomHandle);

If you do use a sequence function, you should place the sentryHandle as your first so that the transaction duration for the api request is as accurate as possible.

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	20.53 KB (+0.01% 🔺)
@sentry/browser - ES5 CDN Bundle (minified)	63.85 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	19.19 KB (0%)
@sentry/browser - ES6 CDN Bundle (minified)	56.92 KB (0%)
@sentry/browser - Webpack (gzipped + minified)	21.66 KB (0%)
@sentry/browser - Webpack (minified)	72.12 KB (0%)
@sentry/react - Webpack (gzipped + minified)	21.7 KB (0%)
@sentry/nextjs Client - Webpack (gzipped + minified)	52.05 KB (0%)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	33.76 KB (+0.01% 🔺)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	26.13 KB (0%)
@sentry/replay ES6 CDN Bundle (gzipped + minified)	44.23 KB (+0.01% 🔺)
@sentry/replay - Webpack (gzipped + minified)	38.28 KB (0%)
@sentry/browser + @sentry/tracing + @sentry/replay - ES6 CDN Bundle (gzipped + minified)	62.45 KB (+0.01% 🔺)
@sentry/browser + @sentry/replay - ES6 CDN Bundle (gzipped + minified)	55.99 KB (+0.01% 🔺)

[AbhiPrasad]

Playing around with wiring up https://github.com/sveltejs/sites/tree/master/sites/hn.svelte.dev

We'll need server-side fetch support for this though (I locally did monkeypatching to get the http.client spans)

[Lms24]

Looks good to me!
Just had a comment about tests.

[Lms24]

m: hmm not really a fan of conditional paths in tests. Makes tests harder to understand and also feels like we're testing different scenarios in one test. To me (maybe just personal preference), it seems like we're misusing each here a little. That being said, if we split the isError cases to separate tests, we probably end up with a ton of duplicated code, right?

I'll leave this up to you: If refactoring these tests results in too much duplication or work, I'm fine with leaving it as is. Generally though, let's try to avoid conditional expects and test paths.

[AbhiPrasad]

Yeah I struggled with this a little, but one of the issues here is that there are 4 different scenarios we need to account for.

1. Async and no error
2. Async and throw an error
3. Sync and no error
4. Sync and throws no error

Let me try cleaning it up so we can remove the isError checks.

[AbhiPrasad]

376291d