Create dataclass to represent DecisionTable selection

[ahouseholder]

Context

• Initial Decision Table object #795
• Should there a optional "references" section in Selection schema? #600
• Add Decision Point Value Selection schema with an example #599
• Generate Decision_Point_Value_Selection.schema.json using Pydantic #735

Description

We need a pydantic dataclass to represent an SSVC selection from a DecisionTable object. A selection object requires at least one mapping row derived from a DecisionTable.mapping but could be any size between 1 and the full set of mappings in the DecisionTable (indicating no input information is available).

In order to keep this task constrained from getting too large, resolving this issue just requires creating the dataclass so we can represent the data. Creation of tools to take decision point value combinations as input and reduce a Decision Table to a selection can be handled in a future issue.

Note

There is already a prototype selection schema that is relevant, although we should not feel strictly bound by it in resolving this issue. Compatibility would be nice but is not required.

[ahouseholder]

The decision point selection object was significantly updated in #821

That object is specifically geared toward representing a set of selections drawn from a set of decision points.

However, the DecisionTable object is more about selecting rows from the mapping value. That's a bit different from what's in ssvc.selection. So I think this is going to wind up being something different from ssvc.selection

[ahouseholder]

While creating the CVSS v4 MacroVector → QSR DecisionTable, we ran across a conflict between two requirements:

• As of Fix a few bugs around Human Impact decision point and decision table #870, we enforce that DecisionTable objects must fully map all input DecisionPointValue combinations
• In Add CVSS v4 MacroVector to Quality Severity Rating DecisionTable #871, we had to work around this requirement because CVSSv4 has some "invalid" macrovectors that are logical impossibilities.

This leads us to a few side effect notes on any implementation of the current issue:

1. A DecisionTable downselect object must not require full input coverage, because that defeats the purpose of being a downselect.
2. Every item in a downselect object mapping must be present in the parent DecisionTable object from which it is derived.
3. We'd probably want some sort of converter method to go from a DecisionTable to the downselect object.
4. That converter might handle CVSS v4 QSR specially, by explicitly removing the "invalid" rows from the mapping (i.e., the rows where EQ3=L and EQ6=H). These would be unreachable by any rational input for the EQ sets anyway.