Add override support.

[davidlehn]

External comment:

Allow an override by package version and OSV URL (so that once a dev looks at the issue, and determines it's not an issue, there is a way for them to move forward w/o having to upgrade in case that would be worse). Package version / OSV URL is a tuple so that an override doesn't apply to a newer version. [...] am fine w/ anything that 1) allows an override to happen, and 2) doesn't make that dangerous for future versions of the software (the vuln showing up in new code for a future version of the software, if that's possible -- this might be an extreme corner case that we're okay with). The goal would to be keep that overrides file as small as possible, having lots of overrides is probably another [use case] we might want to warn on image build.

[davidlehn]

I think overrides would be useful. I think implementing that is challenging in practice.

The OSV scanner does have some support for this. I'm not sure if or how that is usable by this action at the moment:
https://google.github.io/osv-scanner/configuration/#ignore-vulnerabilities-by-id

They do have an effectiveUntil date which would be useful to expire overrides.

An important consideration is the problem of hiding issues. There have been many situations where one package with an issue was present in multiple dependency paths. And we could only update some that we control and simply had to wait for maintainers to update the other paths. That may be sometimes solvable with force overrides, but only after code inspection and testing to make sure an update would work. The usual case there is a fix is in a major version update of some package and that often means there are real reasons a simple forced override would not work.

So that implies what is needed is an override for a parent package version, a target package version, and some issue identifier. I'm not sure what details are available, but they are not in our default tables right now.

We'd also need to update output to show which issues were ignored due to overrides, expiration times, reasons, no longer used overrides, etc. It starts to get to be a lot to manage. But is understandable if these scans are used for more strict blocking of releases that need the control.