remove build system

[ryanatkn]

closes #333

closes #329

Removes the build system and modernizes Gro for SvelteKit, Vite, esbuild, and Node 20 - it now uses a combination of the loader API and esbuild directly with custom plugins for other builds. (only the Node server build at the moment)

There are many breaking changes, and luckily Gro has no users besides feltjs yet so I won't spend the substantial time necessary to document all of them. Some main points:

• add a loader to run TS and Svelte on the fly - https://nodejs.org/dist/latest-v20.x/docs/api/esm.html#loaders
• use svelte-package to publish node libraries - https://kit.svelte.dev/docs/packaging
• tasks are now relative to src/lib/ not src/ (when the build system is removed this will probably resolve from the cwd, then src/, then src/lib/)
• moved dist to .gro/dist to avoid conflicting with the svelte-package output
• remove fs and use all of the synchronous node: APIs, copying SvelteKit's homework
• module import paths no longer have the dist/ segment
• upgrade to prettier 3
• more changes towards removing the build system completely
• deploy from new dist location
• shim SvelteKit's $env and $app
• support the SvelteKit config alias like our $routes pattern
• support Vite's import.meta.env in the loader and esbuild plugins
• build the Node server with esbuild, implement the required esbuild plugins

followup

• consider requiring file extensions for all user imports, using nodenext instead of bundler for the tsconfig moduleResolution and deleting the related complexity in resolve_specifier (maybe finally standardize on .ts extensions?). I like the simple explicit choice of forcing file extension for all imports like ESM requires, but SvelteKit says the tsconfig.json moduleResolution option "bundler" is "the best and recommended option", not "nodenext" which enforces file extensions. On the surface, this seems correct not just to conform to standards and be explicit, but because Gro is not a bundler, it just uses Vite/SvelteKit and esbuild for bundling. We could be more restrictive, and as a user, I may like that explicitness. I'll do this in a followup because things like using .ts extensions may not work with all tooling.
• support task paths so it's not hardcoded to lib, and support 3rd party task deps more elegantly than re-exporting (or maybe that's fine actually?)
• timings shouldn't throw
• detect dirty git and add an override flag
• fix gro deploy --reset
• remove no-install and install from gro deploy and test+document gro deploy -- gro build --no-install to support all options
• change eslint to run on the root, not src/
• sourcemap support
• remove parameterized functions like get_possible_source_ids that's only there for tests and the removed fs system
• consider merging adapt into plugins so there's just one concept and definition (consider an API that lets the callback add itself to an array)
• use join more
• loader caching?
• // TODO delete this?
• rework gro_plugin_gen to be an esbuild plugin, it's currently disabled
• optional/peer dependencies (zod, uvu, source-map-support, figure out the right pattern for the rest too)
• use exported Args in felt - https://github.com/feltjs/felt/pull/920/files#r1308080923