Add OPEV-0014

[puerco]

This PR commits to the repo the document describing the changes for OPEV-0014: Expansion of the VEX Product Field

Fixes: https://github.com/openvex/community/issues/14

[puerco]

Thanks @sudo-bmitch , I've pushed another commit addressing the errors :)

[wagoodman]

I think adding hashes is a solid add, but I can't help but to think back at the SBOM plugfest from a few years ago. One of the notable conclusions was that no single SBOM provider (when given an artifact to analyze) agreed on the full set of hashes for packages in the generated SBOMs --that stuck with me. I don't know if we got down to the specific reasons for this, but one of my suspicions was, given a set of files that represent a package and possible distribution packagings, I could imagine folks taking digests against what they thought was the canonical representation of the artifact (and everyone did something just a little different).

A algorithm name and value is sufficient for getting across the minimum information, but, providing context about what the digest was against could be helpful here. For instance, the purl may indicate this is a python package, and you might have a hash for that package, but was it a digest of the source tar? egg archive? wheel archive? something else? Providing something like a context, comment, or file field could be helpful to add "just enough" context for consumers to be reassured that they at least are comparing apples-to-apples when they find mismatched digests.

That being said, this does not have to land in this PR --this could be an addition to the spec later as well, and adding the capability to capture hashes is a fine first step. (Don't consider this comment as a blocking comment)

[puerco]

Lazy consensus and vote count have been reached. Thanks for your feedback, everybody!!