Prefer artifact relationships over package relationships

[wagoodman]

Context
Today we capture only package-to-package relationships. It isn't possible to express things such as a file-to-package or file-to-file relationship.

The goals of this issue are:

1. Promote relationships as a first class artifact objects raised by catalogers.
2. Enable describing relationships for things other than packages (such as files)

To goal 1: catalogers today only raise []pkg.Package, which means that any relationships you are adding must be added after the cataloging step, after connectivity data may be missing (this is the case for most ecosystems). If the cataloger were to additionally return []Relationship it would allow the catalogers to be more expressive.

To goal 2: Today's pkg.Relationship should probably be promoted to a root-level package. This additionally implies that the existing pkg.ID will need to be replaced with something more agnostic... with additional requirements that anything that wants to express a relationship with something else have an ID that works globally.

This work is most likely coupled to how IDs are expressed in packages; that is, should they remain as UUIDs? or something more stable like a package fingerprint? See #363 for more details.

[luhring]

Could we clarify the definition of "artifact" in the description? I just saw #555, and I like the cleanliness of that direction. I understood the new meaning of "artifact" to be things like "packages", "files", and "distro" — and not "relationships". And a goal of this issue is "Promote relationships as a first class artifact". Will relationships also appear as artifacts in the new design?

[wagoodman]

@luhring the usage of artifact in goal 1 was unintentional --updated.

[wagoodman]

From an offline conversation with @spiffcs : When it comes to forming/discovering/creating relationships, let's make the following assumptions:

1. N-to-M typed relationships (e.g. package to file) must be created after all cataloging is done --these can only be created on the "second" pass.

2. N-to-N typed relationships (e.g. package to package) can be raised up by the catalogers directly (exception to this: relationships across packages of different package types have different catalogers, so can only be created after all package cataloging is complete... that is, this exception case really falls under assumption 1)