Improve node_modules resolver

[calebeby]

This PR finishes some edge-ish cases with resolution:

1. The resolver should look in node_modules folders other than the main node_modules folder. This is important for if you have multiple versions of a package. Also, it is best not to rely on the hoisting feature of npm/yarn that is not guaranteed.
2. The resolver should support symlinks in node_modules. Now it does.

For #1, here is an example:

node_modules
  preact (10.1.0)
  some-library
    preact (8.0.0)

Before this PR, PT only looks at node_modules/preact. This is bad for two reasons, one is that node_modules/preact isn't guaranteed to exist unless we have it as a direct dep, and also, it will always return 10.1.0, even though when importing from some-library, it should return 8.0.0.

This PR fixes that, so it will find the nearest node_modules to the importer that has the requested package.

Both of these changes are necessary for pnpm support. I tested it out by using pnpm with https://github.com/cloudfour/pleasantest-example-modal, linking my local PT in, and making sure the tess pass.

I added tests for #1 but not for #2. #2 can be tested manually:

Testing pnpm

In this repo:

git pull
git checkout good-resolver
npm i
npm run build
npm i -g pnpm
pnpm link --global

Clone https://github.com/cloudfour/pleasantest-example-modal

pnpm i
pnpm link --global pleasantest
npm run test

Closes #176

[Paul-Hebert]

Code looks good and works as advertised 👍 🚢

[Paul-Hebert]

I wanted to flag the warnings above. They don't seem critical and I don't see them as a merge blocker but wanted to make sure you were aware.

(For some reason GitHub wouldn't let me comment directly on them.

[calebeby]

Thanks 👍

I'm not sure whether at this point there is a good opportunity to factor out part of this function. For now I think I'll leave it as-is but I'll keep my eyes out for refactoring opportunities 👀

[Paul-Hebert]

Cool, works for me 👍