rhcc: fix matching for timestamp-based versions

[BradLugo]

rpmver.Parse requires a string in the EVR format (version-release, with
at least one dash). For newer (e.g., Konflux-built) Red Hat images, the
rhcc detector parses a Unix timestamp-based version (e.g., "1744596866")
from the labels.json file and the VEX parser extracts matching timestamp
tags from OCI PURLs, neither of which contain a dash. This caused
rpmver.Parse to reject them with "missing separators", preventing any
vulnerability matching for containers using the new labels.json
metadata.

These changes normalize version strings in the matcher by appending "-0"
when no dash (release) is present, consistent with what rhctag.toEVR()
already does.

[BradLugo]

This seemed like the simplest fix. The alternative would be to adjust the versioning on both sides (i.e., the rhcc detector/IndexReport and the VEX updater/Vulnerability). This way, we can adjust the matcher without requiring any database changes for claircore instances that may already have these non-EVR string versions in their databases. I'm definitely open to alternatives, though.

[BradLugo]

It just occurred to me that this wouldn't work for unfixed versions. Converting to draft and giving that a think.

[BradLugo]

I went the easy route 🤷 I think we should consider throwing an error for rpmver.Parse("-0").

There is an interesting situation with these changes: the rhcc matcher previously didn't match unfixed vulnerabilities. I had thought it was resolved after 1c411ec (#1770 (comment)), but that doesn't seem to be the case.