Deal with SOURCEPKGID, PKGID and HDRID

[pmatilai]

Related to #2633, rpm currently aliases RPMTAG_PKGID to MD5 and RPMTAG_HDRID to SHA1HEADER tags. This doesn't cut it going forward because said tags will no longer be there. In addition there's RPMTAG_SOURCEPKGID which refers to RPMTAG_PKGID.

We can sort of keep these alive by adding tag extensions that provide an identifying hash for the package. Differentiating between the header and the package id was always pointless IMO but even more so in v6 where the main header carries a digest on the payload too. So if we conclude that the header is what identifies a package, then we can conclude that pkgid and hdrid should be the same exact thing. And with >= v4 packages we can always calculate any hash we like on the immutable region, so we can eg use SHA256HEADER as the header ID and dynamically calculate it for older v4 packages that lack it.
Another difference between RPMTAG_PKGID and RPMTAG_HDRID is that the former has been in binary form, whereas the latter has been in ASCII form. That difference we could easily retain if we want - whether it makes sense is a different matter.

Pointing the aliases to something entirely different of course has the potential to break something, but it's either that or those tag names come simply invalid forever.

[pmatilai]

SOURCEPKGID needs to be dealt with along with PKGID because they are linked: SOURCEPKGID of a binary package equals the PKGID of its source package.

To make it all a little more entertaining, SOURCEPKGID is a distinct tag, whereas PKGID and HDRID are just tag aliases. So it indeed seems the only sane way to deal with this is to make PKGID and HDRID extensions that manage the compatibility. And to preserve at least some compatibility, SOURCEPKGID needs to remain binary format, we can use header SHA256 for the data itself in v6 packages, and the PKGID extension then converts SHA256 from hex to binary.
It's a pretty weird mess.