Expose signing algorithm and per-file metadata

[tofay]

Description of changes:
This change updates the PackageInfo struct to expose the algorithm used to sign the RPM, and per file information from the RPM.

Note I've removed the BaseNames, DirIndexes and DirNames fields from PackageInfo as they are superseded by the File information (I think their only use is to derive file information). Let me know if I should add those back in for back-compatibility.

I can also split this PR into separate signing algorithm/file info PRs if you prefer.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice. I expect @wagoodman's confirmation is also required? (This contribution is a rebasing of their commits in https://github.com/anchore/go-rpmdb, which is a fork used in https://github.com/anchore/syft. I'm a syft and trivy user that is trying to remove the need for that fork to resolve anchore/syft#469 😄 )

[wagoodman]

@tofay no permission needed, but thank you for asking -- we've been wanting to get our fork synced upstream (and deleted) this is a huge help 🙏 !

[knqyf263]

The original idea of this library is to mimic the behavior of RPM as much as possible. This is because it makes it easier to keep up with upstream changes. Also, this library is basically for general usage. That is why I kept DirIndexes, etc and return installed files via function since RPMTAG_INSTFILENAMES is a virtual tag, not an actual field. From that perspective, I prefer having file attributes in PackageInfo as is and returning FileInfo through Files() or something like that. What do you think?

It is not so strong opinion. If you think my idea has a big penalty of performance or readability, I'm ok with the current implementation.

[tofay]

I'm happy to with your suggestion (I think it makes it more readable), so I've gone with that.

Do we need to expose separate functions for getting FileInfos and just file paths?
I thought not (but don't feel strongly about it), and updated InstalledFiles to return FileInfos. Is that ok?

[knqyf263]

I thought not (but don't feel strongly about it), and updated InstalledFiles to return FileInfos. Is that ok?

Can we rename InstalledFiles to InstalledFileNames and keep it so that we can comply with RPMTAG_INSTFILENAMES? Then, InstalledFiles can return FileInfo.

[tofay]

Thanks for the feedback - I've now done that so there is both an InstalledFiles and an InstalledFileNames

[knqyf263]

Thank you so much!!