Expose file resolution as a utility

### What is the problem this feature will solve? Tool authors often need to reimplement Node's resolving behaviors in order to ask the question: if *this* file was to import *this* path, which file would Node resolve that to? This comes up for build tools like Vite, Esbuild, or Webpack. It also comes up for analysis tools like Eslint and Typescript. For a long time, people were able to get by with the likes of https://www.npmjs.com/package/resolve. But the introduction of the full suite of package.json `exports` features (conditions, subpath imports, etc) and ESM have resulted in a situation where almost no tool actually covers Node's complete spec correctly anymore. It seems wasteful to try to fix all these parallel implementations rather than share node's implementation as a utility. ### What is the feature you are proposing to solve the problem? A node-provided, importable constructor that takes [conditions](https://nodejs.org/api/packages.html#resolving-user-conditions): ```ts import { Resolver } from 'node:resolver'; let r = new Resolver({ conditions: ['default', 'node', 'development' ] }); ``` Where the `Resolver` instance offers a method with the signature: ```ts resolve(requestedPath: string, requestingFile: string): Promise<string | undefined>; ``` The key features provided here that are not provided (AFAIK) by any existing Node API are: - you can programmatically ask what would happen under the given [conditions](https://nodejs.org/api/packages.html#resolving-user-conditions). These are distinct from the global `--conditions` that prevail in the current node process (remember -- we're talking about running this inside a tool like a linter. Regardless of what conditions the linter uses for its own implementation, it should follow imports the way the *user's* program is going to do it, using the *user's* conditions.) - you can ask on behalf of another file in another package. Critically, this would need to respect rules like [self-referencing](https://n…