Partially implements #572

Adds dependency relationships between python packages installed within site-package directories. This only associates packages that are either:

• within global python installation site-packages dir
• within a virtual env site-packages dir (which explicitly does not link to a global site package dir)
• across a virtual env site-packages dir and global site-packages dir (when the pyenv.cfg indicates to do this)

This adds indications of Requires-Dist, Provides-Extra, and Requires-Python to the existing pkg.PythonPackage metadata struct.

The extras field is only partially supported, in that, if package A has an extra declared that will install package B conditionally, and package B is also found to be installed, then there is a relationship explicitly created that links B dependency-of A, even if A was not installed with any extras. There are a couple of reasons to do this:

1. there is not (as far as I can tell) a great way to really determine if a package was installed with extras in a declarative sense, really the existence of installed packages is the best way to do this
2. many python packages have try/except clauses around dependencies that are conditionally installed via extras. If the package happens to be installed anyway, then the import will function, and it would be as if the user installed the package with that particular extra (in the simplest of cases). In that way, even if an extra is partially installed, there is a chance that that dependency would be used, so we make the relationship.

What is not supported in this PR is validating any version constraints from any Requires-Dist declaration... if the package is installed, then it is assumed that the virtual environment is valid and consistent... so pip or other tooling has already performed to correct version constraint processing during installation.

Regarding changes made to cataloger/generic: In this particular instance we could not use exclusively material that was already present on packages, we needed to gather additional material via the file.Resolver to do so. Additionally, this material pyenv.cfg is not evidence for any single package, but instead configuration for an entire virtual environment, so didn't belong as additional data attached to package metadata. For this reason a new pattern was added next to generic.Processor, called generic.ResolvingProcessor as to not make any breaking changes.

I did decide that users should be able to specify both Processors and ResolvingProcessors in the same slice of post-cataloging processor functions, so that callers can closely control the order between these two kinds of processors. This lead to additional non-exported interfaces to facilitate this (and added more complexity than I wanted) but seemed like the best way to achieve the stated goals.

Lastly, this rearranges some internal functionality for necessary re-use (specifically using the relationship.Index capability). This caused additional utility functions to be moved because of this (otherwise it would be called binary.RelationshipIndex which makes no sense).