Not covering this basic aspect of how real project roots actually work
allowed a windows bug to hide until real data came through - #146.

This was never used, because it wasn't actually needed.

ExternalReach (to be renamed presently) was producing only a list of the
externally reachable packages from the input set. This is the most
important requirement, but there's also a need to keep track of which
internal packages are (transitively) imported within each project.

Without returning an internal reachmap - a list of all internal packages
reachable from each other internal package - we end up recording only
those packages from projects that were directly imported across project
boundaries. Those packages that are only imported by other internal
packages are missed.

Fixes a dumb error, but there's still an intermittent problem. Testing
failures suggest a random map iteration order issue.

The old logic was a holdover from before a proper depth-first search
algorithm was implemented in wmToReach(). It was trying to do a "bit" of
the search work before the real algorithm; however, the final else
statement was causing some internal imports to be dropped if the
referent had already been visited. The bug was intermittent, as it
depended on map iteration order.

This also solves the secondary problem of inaccurate
backpropagation/poisoning in wmToReach itself, as the internal linkage
data it's operating on is now reliable.

Rather than splitting the data into two separate map return values, this
makes ReachMaps' value a struct containing both the internal package
import and external import path list information.

Much better name. Also adds the capability of filtering out stdlib from
PackageTree imports, addressing #113.

This second parameter provides information about why a package was
dropped from the ReachMap - either what problem it had itself, or the
problem in one of the internal packages it transitively imports.