Add yardstick labels symlink to gitignore

[wagoodman]

A few changes were made in this PR:

• while troubleshooting it would have been nice to see a little more information in the output, so verbosity has been increased
• similarly, there is nice formatting that is disabled due to the environment, so I've forced it to be enabled
• the labels should never be behind or we risk not building a DB due to stale labels. I've updated the git submodule to track the main branch of the vulnerability-match-labels repo. If ever there is an issue in the future, we can pin back to a specific version.
• the .gitignore was incorrectly ignoring the data/yardstick/labels directory. This has been corrected.
• bumped the unlabeled matches gate from 25% to 35% as a workaround for v1 and v2 rpm epoch issues.

More on the gitignore change...

This is not valid:

# .gitignore
/data
!/data/yardstick/labels

Tip of the hat to https://stackoverflow.com/questions/3203228/git-ignore-exception/72380673#72380673 on this one.

When running the production run yesterday there were no relative comparison differences so the labels were not used. However, today there happened to be differences, so the labels were attempted to be used, but the link was not checked in, so it was as if there were no labels. The gate (correctly) failed since there were too many matches that were unlabeled.

[wagoodman]

It looks like the v1 and v2 schemas will not pass validation. A further look shows that this is mainly due to the fact that RPMs at these grype versions did not have epoch captured, thus the labels are not matching appropriately.

Adding labels for these matches is not the right thing to do since they would not be accurate. Adding an exception to not validate the v1 and v2 DBs also isn't a good idea since we still want to protect against possible publishing issues. We could bump the gate configuration, however this will apply to all images for all DB schemas. This last approach is the lesser of all evils, so I'll make that update here, but ultimately we need to drop support for v1 and v2 schemas in the near future (which was always the plan).