Add legacy PackageVerificationCode as an integrity method

[goneall]

This pull request adds a legacy package verification code.

Based on the PackageVerificationCode as part of the security profile team call on 12 Jan 2023, we agreed that the model itself support package verification as is as long as we have additional documentation. We decided to postpone the decision on how to handle the legacy package verification codes until after RC2.

This PR is a placeholder for possible inclusion if we decide to add the legacy support.

[kestewart]

Thanks for pulling this together, would like to include it.

[nishakm]

Pending decision after RC2 is released. Per discussion in the SPDX tech meeting dated 2024-01-16, there are use cases where inclusion is required.

[goneall]

@nishakm @kestewart @jeff-schutt - Could you connect on whether this needs to be included for RC2? I'll go along with any decision the 3 of you agree on.

Note that if we do want to include it, we need to decide if this is an enumeration in the hash algorithms + some way of adding excluded files OR if we go with this PR. I do have an opinion on which way we go and I believe @zvr and @maxhbr also have opinions.

[kestewart]

I met with @jeff-schutt after the meeting, and discussed the use cases. He was ok with this going in. @nishakm do you have any reservations other than the missing work for exclusion case?

[maxhbr]

LGTM

[nishakm]

I met with @jeff-schutt after the meeting, and discussed the use cases. He was ok with this going in. @nishakm do you have any reservations other than the missing work for exclusion case?

No reservations. LGTM.

[xnox]

Is this required to produce if backwards compatibility is not needed?

[goneall]

Is this required to produce if backwards compatibility is not needed?

No - there are other verification methods which can/should be used such as using the gitoid property on artifacts.