[WIP] sketching part of solution for compatModules in v2 addons

[ef4]

Opening a draft to record current work on how compat-modules should work in v2 addons.

we need to also solve the modulePrefix='.' issue. My current thinking is that this should be an embroider config option (since embroider config already controls the contents of compat-modules, like staticAppPaths)
this implies we should also refactor the embroider config management to always live in vite.config as options to the ember plugin(s), rather than pass it through ember-cli-build.js.
it's a troll to not include the v2 addon's own appReexports. But that config is currently down inside rollup config, where it doesn't effect vite dev at all. Need to design where it should live instead. (Probably also in the embroider config, in the arguments to the vite plugins.)
we need to be careful with engine detection. Engines are addons but have existing app-tree behavior that should not get confused with this new support.

[ef4]

Notes from tooling team pairing:

The next implementation step is refactoring config handling so there's a dedicated embroider config file for user-controlled options, and the first step toward that is cleaning up the structure / types of four existing interfaces.

We currently have two layers of user-facing Options interface (the one in core and the one in compat) as well as two layers of the Resolver options (the content of the resolver.json, which is also the argument to the Resolver construction): the core one and the one extended by the resolver transform. This layering leads to casting and confusion.

The extended config that isn't really used by Resolver shouldn't be part of resolvers own options just to ride along to be accessed as resolver.options.*. Instead we should generalize ResolverLoader to be a ConfigLoader that can directly give you config as well as give you a cached Resolver based on that config. The types should use composition instead of inheritance so that things the Resolver never uses are not in its argument. Some fields like splitAtRoutes are still core features, but not Resolver features.