Add getPackageInfoForId API

[bterlson]

It is often helpful for other plugins to get a module id's associated package.json. For example, rollup-plugin-commonjs wants at to at least:

1. Consult package.json for its module name in order to know whether a user has configured named exports for that module.
2. Consult package.json's types field to infer exported members from TS type information.

Unfortunately, finding a package.json given a module id is slow and error prone, and shouldn't really be done by each plugin since this plugin has already loaded the package.json during its resolution process.

So this PR exposes an new plugin API, getPackageInfoForId, which contains the following information:

• packageJson: the original package json file (unmunged, and so different than its internal package json cache).
• packageJsonPath: path to the containing module's package.json
• root: package root directory
• resolvedMainField: the main field used during resolution, either 'main', 'browser', or 'module'.
• browserMappedMain: whether the browser map was used to find the entry point
• resolvedEntryPoint: the entry point after all mappings were applied

Note this bit of complexity: you can end up with resolvedMainField as main while browserMappedMain is true and resolvedEntryPoint is browser-mapped. This happens when a package uses a browser map object (rather than just a string) that happens to map main or module.

/cc @lukastaegert since this was your idea, appreciate a review 😁

[bterlson]

@lukastaegert I believe I've addressed your comments. Can you please take a look, and let me know what you think of the docs too?

[bterlson]

Added another commit that cleans up realpathing some, as I noticed a bug wherein package.json browser mappings wouldn't work with realpaths. Now, if you have preserveSymlinks: false, your package.json browser fields should specify real paths.

This is a breaking change, for the record

[bterlson]

Also updated https://github.com/rollup/rollup-plugin-commonjs/pull/420 to use this new API.

[shellscape]

I'm gonna push this one through. We're ramping up to get this migrated to rollup/plugins as one of the last four to be moved.

[bterlson]

@lukastaegert is right re: find vs. filter[0], which I want to fix. I am also a little confused as to the preserve-symlinks semantics outside of node_modules folders, and want some test cases to make sure the realpath change is either doing the right thing or, possibly, made no change in practice. We'll also need to discuss versioning to release this - hoping a semver minor will be sufficient once the aforementioned investigation is complete.