Environment API experiments

[Rich-Harris]

this is just a place to experiment with the work started in sveltejs#12637

thoughts, in no particular order:

• if we use a pragma to declare which runtime belongs to which route, we can put it in the manifest data
• maybe adapters should be able to influence the Vite config (in addition to creating environments, they could set aliases etc)? Then again there probably aren't many things they should be responsible for, so the conservative thing to do would be to just rely on them to create environments yeah I'm pretty sure this is a no
• we need to be able to use alternative runtimes during postbuild and preview. this feels a bit 'draw the rest of the owl' right now
• there's way too much boilerplate — it should be possible to make the entry points way simpler. like, maybe instead of importing Server and instantiating it with other stuff you imported, you should just import server and it should come with properties like base and methods like server.isAsset(request) and server.isPrerendered(request) already configured
• feels like adapters shouldn't have to worry about getClientRequest in dev
• same for read — in prod the adapter needs to provide an implementation, but in dev surely it only needs to say whether or not it's supported (and this should mean we no longer need all the finicky AsyncLocalStorage/before_handle stuff to determine whether or not it's being used in a route that doesn't support it)
• we can deprecate request.platform and the emulate function on adapters, neither is needed in this new world

thoughts on the Environment API itself

• wow this is complicated. the ontology is huge
• wow there's a lot of boilerplate
• feels awkward that we need to jump through hoops to make a Node environment API that we can use for SSR. This seems like such a core use case. The dispatchFetch stuff feels ropey
• the process of creating a ModuleRunner seems very elaborate. would love to see a much simpler API here