vulnerabilities: Improve the representation of the severity and its handling

[fviernau]

advisor data model

The data model of the severity of vulnerabilities aka. VulnerabilityReferenceis not very strictly typed.
So, it provides too much flexibility which introduces unnecessary complexity and the handling in multiple places is not as straight forward as it could be. A more stricter typing would help, e.g.:

1. Introduce an enum for the known scoring systems
2. A severity should become a tuple (scoring-system, value) whereas value is a lossless representation of
   the severity, e.g. in CVSS this would be the vector (not the score).
3. Have a UNKNOWN scoring system, for which the value is free text.
4. For each scoring system, have a function getScore() (and maybe getScore range) for a number representation and getTextValue() for a textual representation.

Question: Should we use a severity list (like OSV does) to allow multiple representation of (the same) severity in different scoring systems, or stick to a single one? (I'd slightly tend towards a list to allow for a straight forward / non-opinionated mapping from the OSV data model)

evaluator / policy rules

In the evaluator the use case is to take vulnerabilities from the advisor and create violations if any.
The relevant part / question in this context is how to best map the severity tuples mentioned above, to
the severity of a rule violation. I propose the following

1. The mapping from the advisor vulnerability severity to the severity of the corresponding rule violation should be completely user configurable. Therefore this should happen in the policy rules itself. However, ORT could provide a reasonable default implementation as a function of the rules API or alternatively as a function in the default or example rules.
2. For the rule violations I believe mapping to ORT's severity (ERROR, WARNING, HINT) is fine but that should be agreed upon upfront.

evaluated model

Fix the conversion from severity to text.

[sschuberth]

This relates to addressing the issue mentioned here. The idea that I mentioned in a community meeting was to refactor the CVSS classes into a sealed class hierarchy.