Support .npmrc public hoisting settings

[alexeagle]

If the user has https://pnpm.io/npmrc#public-hoist-pattern and/or https://pnpm.io/npmrc#shamefully-hoist in their .npmrc, we should honor these and lay out our node_modules symlinks into the virtual store in the same way pnpm would.

These hoist dependencies matching the pattern to the root modules directory. Hoisting to the root modules directory means that application code will have access to phantom dependencies, even if they modify the resolution strategy improperly.

Note: as a temporary, partial measure, we have the public_hoist_packages attribute of https://github.com/aspect-build/rules_js/blob/main/docs/npm_import.md#npm_translate_lock and you can find an example usage of that buried in https://github.com/aspect-build/rules_jest/blob/main/scripts/mirror_release.sh#L40-L44

[gregmagolan]

Prefactors for this underway,

https://github.com/aspect-build/rules_js/pull/246 landed

https://github.com/aspect-build/rules_js/pull/260 in review

[gregmagolan]

#260 landed;

next up on the list is to figure out how pnpm decides to hoist if there are multiple versions of a package. for semver comparisons it likely decides to hoist the latest; but what does it do if one of more of the choices are non-semver versions of a package such as,

"debug": "ngokevin/debug#9742c5f383a6f8046241920156236ade8ec30d53",

[alexeagle]

@octogonz might be up for helping us emulate some of these finer points of pnpm behavior, if we need an expert rather than read pnpm sources ourselves