Externalise framework dependecies and split configs

Happy to move this to a discussion if issues are not well suited, this might need some discussion

Feature Request

1. Let the user specify its vite, svelte or @sveltejs/vite-plugin-svelte versions in the project's package.json instead of wrapping all under wxt or @wxt-dev/module-svelte.
2. Let the framework configs be separate, from the wxt.config

// project-using-wxt package.json
{
  "devDependencies": {
    "@sveltejs/vite-plugin-svelte": "^7.0.0",
    "svelte": "^5.0.0",
    "vite": "^8.0.0",
    "wxt": "^0.20.20"
  }
}

/project-using-wxt
  /src
  svelte.config.js
  vite.config.ts
  wxt.config.ts

wxt needs then to just specify the expected deps in peerDependencies:

{
  "peerDependencies": {
    "svelte": "^4.0.0 || ^5.0.0",
    "vite": "^6.0.0 || ^7.0.0 || ^8.0.0"
  }
}

and consume the relative framework's config

Looking at @wxt-dev/module-svelte, I guess that this kind of packages exist to have an unified config, but I'd argue that the tradeoff of a single config it's not worth the problems that it creates, specifically:

1. some tools (like svelte-check, the svelte typechecker) need to look at the svelte.config file to figure stuff, like if you have the async flag enabled, which they fail to if the conf are under the wxt.config.
   I think wxt should support frameworks options and not viceversa.
2. in monorepo environments, the dependency tree of a wxt project might intersecate with the tree of others, leading to projects sharing dependencies version when the should not.

People may have very exotic constraints, e.g. when I updated another project in a monorepo to vite 8, that vite version get passed down the wxt project and its subdependencies as well, while i need it to stay fixed at vite 7.
Specifically the @wxt-dev/module-svelte@2.0.5 gets stuck with @sveltejs/vite-plugin-svelte@6.2.4 which does not support vite 8, making pnpm complain.

I'd also argue that this change could allow wxt to be more framework agnostic, making it easier to use whatever framework with whatever combination of libraries.

Is your feature request related to a bug?

Look at the section above

What are the alternatives?

1. I was not able to find a solution, i reverted back to not using async svelte;
2. Overriding the dependencies, which feels like a maintainability burden.

How it might evolve

Perhaps this could also spark some bigger refactor to make the core wxt a thinner layer on top of vite, even a plugin like @sveltejs/kit is, while preserving the fantastic features and allow more extensibility in the future. Like extracting the cli in its own package invocable by npx,
I may be biased (I love svelte and sveltekit 😅) but i think the sveltekit way of handling its environment is the top notch experience.

I think that having the svelte's control and ergonomics with the nuxt's DX will make this the no-brainer framework for web extensions.

I'm not able to speak for other frameworks, but if you need some help to test svelte's edgecases I'm happy to help.

Start by reviewing @wxt-dev/module-svelte and the package.json, wxt.config.ts, svelte.config.js, and vite.config.ts examples described in the issue. Trace how framework dependencies and configuration are currently consumed, then define the required peer-dependency and monorepo behavior. Done means framework versions and configs can be controlled by the project without breaking existing WXT workflows.