Enrichment: Fixed versions, safe versions

### Current Behavior

Fixed versions can be inferred on a per-vulnerability basis, given the vulnerable version ranges:

* If the range has a `< X.Y.Z` constraint, `X.Y.Z` is a fixed version
* If the range has a `<= X.Y.Z` constraint, any of `(X+1).0.0`, `X.(Y+1).0`, `X.Y.(Z+1)` could be fixed versions
* *(Heavily simplified, it's almost never as trivial as to increment a version part)*
* *(Existence of those versions would need to be verified)*
* If the range only has `> X.Y.Z` and `>= X.Y.Z` constraints, there is no fix.

Additionally, some sources may explicitly report fixed versions.

This is nice for individual vulnerabilities, but it doesn't necessarily make the developers' jobs easier:
Bumping versions to fix one vulnerability might open the door to new vulnerabilities.

The real question is: What version can you *safely* update to, that is affected by **no** known vulnerability?

### Proposed Behavior

As an enrichment step, analyze version ranges across all vulnerabilities affecting a component.

Try to work out which version is not, or is very unlikely to be, vulnerable.

Could leverage [deps.dev](https://deps.dev/) here to verify the existence of component versions if necessary.