fix: resolution map paths should be relative to project

[tomdale]

BREAKING CHANGE: This commit changes paths in resolution map objects (produced via the buildResolutionMap() function) to be relative to the project, not the src directory. It does not change the final generated source code, so does not impact existing Glimmer.js applications. Anyone using this functionality today is hardcoding src before paths, so resolving the compatibility change just means using the path as-is and discontinuing hardcoding src.

The intent of the resolution map object is, ultimately, to generate JavaScript code that imports modules and maps them on to Module Unification specifiers. While this system currently only supports addressing app modules via Module Unification, the intent has always been to make multiple packages addressable. For example, addons may want to contribute modules to the app's resolution map. In that case, the resolution map might look something like:

import __my_component__ from '../node_modules/my-component/src/ui/components/MyComponent';

export default {
  "component:/my-component/components/MyComponent": __my_component__
};

While the paths generated by buildResolutionMapSource() are correctly relative to the app's config directory, the data structed by emitted buildResolutionMap() contains paths that are relative to the src directory—thus the system is hardcoded to only support files that originate in src.

This commit makes two changes:

1. Paths in the resolution map object are guaranteed to be relative to the project directory, not src. This means we can support other directories in the future, such as lib/, node_modules/, etc.
2. The source code generator calculates relative paths from config/ to the provided path and does not hardcode src/.