feat: support multiple node_modules roots in require_patch

[tcarrio]

Refs: #266

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature (please, look at the "Scope of the project" section in the README.md file)
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

When referencing multiple node_modules from (npm|yarn)_install targets in a nodejs_(binary|target), you won't be able to resolve modules from all node_modules roots.

For example, having a separate yarn_install:

# setup stencil spec test dependencies
yarn_install(
    name = "npm_stencil_spec",
    exports_directories_only = True,
    frozen_lockfile = True,
    package_json = "//tools//stencil:spec/package.json",
    package_path = "tools/stencil/spec",
    yarn_lock = "//tools/stencil:spec/yarn.lock",
)

alongside the root:

yarn_install(
    name = "npm",
    data = ["//:.npmrc"],
    exports_directories_only = True,
    frozen_lockfile = True,
    package_json = "//:package.json",
    yarn_lock = "//:yarn.lock",
)

and referring to both of them in a test rule:

nodejs_test(
    name = "test",
    args = [
        "test",
    ],
    chdir = native.package_name(),
    data = [
        "@npm//@stencil/core",
        "@npm_stencil_spec//jest",
    ],
    entry_point = stencil_cli_path,
)

would result in the test run not being able to access the jest module.

Issue Number: #266

What is the new behavior?

Resolution of a require call will be done against all node_modules roots. The behavior is the same if it is not found.

Does this PR introduce a breaking change?

• Yes
• No

The prior behavior would have allowed for node_modules to be included without being able to be imported. Due to this, if anyone were relying on this undefined behavior to include node_modules data where importing that would have thrown an error, but I can't imagine a use case where this would be useful behavior to rely on.

Other information

Some minor adjustments to test case names such as "mode" updated to "module".

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[tcarrio]

This one will likely require updates to the linker as well. I will be working on that further. I will open my discussion in the linked issue to go over how this should work.

[alexeagle]

Hey @tcarrio it's exciting to see you're diving into this area. You could come chat in #javascript on slack.bazel.build to coordinate with @gregmagolan - we are also thinking about refactoring the linker.