Add python wheel egg relationships

[wagoodman]

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).

[spiffcs]

Glad to see the relationship index being useful over in other ecosystems!

I don't have any comments blocking this to merge. I tried it on a couple of anchore projects written in python to get an idea of the before and after for what new relationships show up and it all LGTM as far as what was expected to be added appeared with this branch.

The schema bump is 🟢 so no comments there.

This comment was covered in the summary. There was a new processExecutor private interface added with a private function.

So resolvingProcessorWrapper implements processorWrapper which embeds the public ResolvingProcessor

I agree that it's complex and took me a little while to get a mental model of how everything behaved. I like how it works now and can get on board with the tradeoffs made here.

There was a dependency_test.go stubbed out syft/pkg/cataloger/python/dependency_test.go did you mean to go back and fill this out or delete it?

I tried a couple different configurations for virtual env and found syft/pkg/cataloger/python/virtual_env.go worked, but suspect if there is anything I missed it's in this file as I don't have a great mental model of all python virtual env configurations or if there is something missing here.

[wagoodman]

There was a dependency_test.go stubbed out syft/pkg/cataloger/python/dependency_test.go did you mean to go back and fill this out or delete it?

indeed, I was going to add a test here but then realized the code in question was already covered... however, I have a follow up PR #2906 that will add a test in this file, so I'll leave this for now.

[wagoodman]

note: force pushed to rebased on main (resolving conflicting schema changes)