npm / arborist / #103

push

Rework approach for finding link target deps

This change updates a few things, resulting in a much more resilient and
reasonable approach to finding the dependencies of link targets, which
is relevant for workspaces and for interpreting pnpm trees, and reduces
the "load my whole dev folder" antipattern.

Prior to this change, in loadActual, if a link target was found in a
node_modules folder, then the parent of that node_modules folder would
be loaded, along with its children.  While this is seems like a
reasonable way to handle pnpm trees, it has the following problems:

1. If you are developing a bunch of projects right in a `node_modules`
folder, then it would sometimes result in loading ALL of your JS
projects in the actualTree!  This is rarely what you want, and had some
surprising behavior when I encountered it myself.  (I develop quite a lot
of projects in a node_modules folder for convenience.)

2. If you have a situation where a package is _not_ in a node_modules
folder, but it does have some missing dependencies which are in fact
resolved by deps already in the tree, it would show up as missing.

With this change, the loadActual process will walk up the parent
directories of any top nodes, searching for any missing edges.  If a
folder is found at `${dir}/node_modules/${name}`, then a "dummy" node is
created for the parent, such that the parent/fsParent resolution
algorithm will find a hit and resolve to the named dep.

It will not load any _other_ dependencies in the dummy node, however,
and will not walk up higher than the nearest common ancestor of the
project root and the link target.

Furthermore, this uncovered a bug where setting the parent of a node to
a new parent with the same `root` was causing it to unlist itself and
all children from the root.meta and root.inventory, but only _relist_
itself, and not its children.  This bug was previously not hit in test
because the node demonstrating it was within a node_modules folder, and
so ... (continued)

1854 of 1854 branches covered (100.0%)

Branch coverage included in aggregate %.

2781 of 2781 relevant lines covered (100.0%)

221.54 hits per line