Publish `exports` and `imports` implementations as separate module(s)

### What is the problem this feature will solve? Projects implementing support for module resolution have to add support for the quite advanced `exports` and `imports` fields in package.json. https://nodejs.org/api/packages.html#exports https://nodejs.org/api/packages.html#imports Examples of projects that have done this are Webpack, TypeScript, Jest (only `exports`, not `imports`), Yarn and probably more. AFAIK neither Rollup, Parcel or Metro (to name some bundlers) have support. ### What is the feature you are proposing to solve the problem? If the algorithm Node uses internally was published as a separate module, I hope (and believe) more projects would be able to add support more readily, and that ecosystem compatibility would improve as a result. I think part of the reason is the complexity in supporting the algorithm needed, particularly with subpath exports, wildcards and conditionals. E.g. https://github.com/browserify/resolve/issues/222 is stuck, and https://github.com/facebook/jest/issues/9771 took a _long_ time. Prior art for externalizing parts of Node publishing [`cjs-module-lexer`](https://github.com/nodejs/cjs-module-lexer) separately, which means Jest could implement the same feature as node itself when importing CJS from ESM (via `vm` API). --- Note that this is _not_ a request for the full `require` or ESM resolution algorithm. This is solely a request for "given this `exports`/`imports`, this specifier and these conditions, what path does it map to" - no FS access/lookups at all. API similar to https://github.com/lukeed/resolve.exports makes sense to me. ### What alternatives have you considered? Jest (and Yarn) currently use https://github.com/lukeed/resolve.exports to avoid having to implement all the resolution. It currently does not support `imports` (https://github.com/lukeed/resolve.exports/issues/14).