feat: server side route resolution

[dummdidumm]

This PR adds server side route resolution to SvelteKit. This means that instead of loading the whole routing manifest in the client, and doing the route resolution there, the server runtime is invoked for each route request.

How this works:

• user clicks on <a href="/foo/bar">..</a>
• server call to _app/routes[route].js, so in this case _app/routes/foo/bar.js
• SvelteKit server runtime does route resolution (does this match a route, taking reroutes into account etc) on the server and returns a response that is a JavaScript file containing the route information in a format that can be parsed on the client

What this enables:

• Projects with massive routes can use this to not send so many kilobytes up front to the client, because the client routing manifest would no longer be sent
• You can hide what routes you have
• Because the server is hit for every route resolution, you can put things like edge middleware in front and be confident it is always called, and for example do rewrites (for example for A/B testing) in there

TODO:

• add an option for this (router.resolution = 'client' | 'server') or sth like that
• validate option such that you cannot combine it with hash routing or another bundle strategy than "split"
• use said option to generate a boolean so that we can treeshake code on the client / not load the client manifest / etc
• tests
• docs
• enhance adapter API such that it's possible to deploy this as a separate route, so for example it can be deployed to the edge on Vercel (wasn't actually needed, you can do it with the existing APIs)

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

🦋 Changeset detected

Latest commit: 27a8243

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@sveltejs/adapter-vercel	Minor
@sveltejs/kit	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-13379-svelte.vercel.app/

[Rich-Harris]

alright I think this is ready to go! The edge function generated in adapter-vercel still has a lot of dead weight — it includes all the Svelte rendering code, even though there's nothing to render — but I think it would be reasonable to tackle that later rather than blocking on it

[kkarikos]

I tried to test this out by having route resolution set to "server".

Our scripts are hosted on CDN in different subdomain than the application. I noticed that the call to __route.js is sent to the https://cdn.example.com/route/__route.js instead of https://example.com/route/__route.js. Not exactly sure what is causing this behavior but it seems like a bug.