refactor: structure overhaul

[pi0]

This PR splits the Nitro codebase into logical scopes separated by subpath exports.

• nitropack/cli: Nitro CLI. Will be used for standalone zero dep CLI package in the future
• nitropack/core: Main utilities exposed for programmatic usage, dev and build + app (same as nitropack for now)
• nitropack/runtime: Core server runtime logic (see notes below)
• nitropack/types: All types unified in a single place (see notes below)
• nitropack/config: Config type helper (loader, defaults, and normalizers live in core)
• nitropack/kit: Possibly reusable utilities for module and preset authoring as well as external integrations
• nitropack/presets: deployment presets (runtime, config, types) (#2446)
• nitropack/meta: exposing current version (alternative to package.json imports - ca2282bb4f08a0fa5f65befae2d29d0ccaf6dae1)

[!NOTE] This PR introduces lots of changes to the current 2.x codebase in order to make sure we can keep supporting Nitro 2.x for a longer term in parallel to Nitro 3.x. A lot of thoughts have been put in to make sure we don't intentionally break any common or documented usage. There is still a chance that some changes introduce regressions. We will keep investigating to find and resolve them as much as possible via Nitro nightly channel. If you spotted any, please feel free to open an issue and describe the case 🙏🏼

What happened to types?

Currently, types are split in several places from core, bundler, and runtime and exported from several places. Now they are unified and accessible from (type-only) nitropack/types subpath.

[!NOTE] This change is likely break-in usages augmenting Nitro types from "nitropack" subpath. This will be addressed in a subsequent PR after better testing via a backward-compatible polyfill.

What happened to the core?

Externally, almost nothing. Exactly the same exports are preserved for compatibility. Internally, some important major refactors happened:

• Config loader and resolvers moved to modular core/config
• Core logic (nitro.ts) split into scan utils and config resolvers
• Builder utils split into modular units for better maintenance

What happened to runtime?

One of the messy parts of the current code structure was runtime. It was:

• Exposing all internal utils
• Exposing userland utils (for auto imports)
• Exposing preset internal utils
• Available as #internal/nitro or #internal/nitro/* for import

To add to the complexity, the virtual files were ALSO exposed in the same #internal/nitro/virtual namespace.

The new structure makes it much cleaner:

• nitropack/runtime: Exposing userland utils (same as auto imports)
• nitropack/runtime/internal/*: Exposing internal utils. Users and frameworks should NEVER EVER use them they will be soon protected as well to prevent wrongly importing from this namespace this is because we need to improve nitro internal implementation without imposing breaking changes
• New virtual (+internal) imports:
  • #nitro-internal-pollyfills
  • #nitro-internal-virtual/*

Since this PR is landing for Nitro 2.x, to avoid breaking changes in projects and frameworks that for any reason had to use #internal/nitro, there is a compatibility layer with minimal known usages (mainly from Nuxt codebase), they are maintained in src/runtime/_compat.

What is the new kit?

The new nitropack/kit exports common but shared utils + define helpers. More will be added in the next steps

• defineNitroPreset and defineNitroModule
• writeFile, isDirectory, prettyPath, resolveNitroPath

[pi0]

(this PR is likely making unsen regrssions as mentioned above and merge is intended to identify them end-to-end and fix in nightly channel progressively)