Remove markdown formatting from the Safety Decision point

[ahouseholder]

This issue could be made redunant by a solution to

• Revise Safety decision point value text #482

Otherwise, at present, we have HTML content in the description of the Safety decision point following the merge of #479. The end result, as described in that PR

• make safety table formats look better #479

is that the JSON file emitted contains that HTML markup, and it really should not.

One approach would be to add a wrapper method on the SsvcDecisionPointValue class in src/ssvc/decision_points/base.py to strip out HTML from the description field when calling the to_json method provided by the dataclass_json decorator.

Another approach could be to override the encoder for _Base.description in src/ssvc/_mixins.py. See for example https://pypi.org/project/dataclasses-json/#Overriding

[ahouseholder]

Note

We are no longer using Python's built-in dataclasses and have (as of #674) switched to using the Pydantic BaseModel equivalent. So the override description above is no longer accurate.

[ahouseholder]

I think resolution of this really comes down to a choice between:

1. We allow markdown and html in the description fields of the python objects, but strip it out when dumping to JSON. This can be achieved with a field_serializer

@field_serializer("myfield")
def serialize_myfield(self, value: str) -> str:
    return strip_markdown(value)

2. We disallow markdown/html in the description fields. Manually enforced by convention & PR review.
   2a. We create a new minor version of the decision points that currently contain markdown/html and just don't do that anymore.

I'm leaning toward (2) because it's less customization on our object serialization / deserialization process. If we were to implement (1), we'd be in a state where you could put rich content in but the thing that gets emitted is stripped of that rich content, and the process of stripping it could result in confusing or misleading representations downstream. I think it's better if we just enforce that whatever you put in those strings will be faithfully serialized, and if you don't want formatted things, then don't assign formatted values.

If there's a third option, I'm interested to hear it. Also open to discussion of why (1) would be preferable to (2) that also addresses the above concern.

[j---]

I think (2) makes more sense.
The HTML in safety was a cludge on a cludge from when I was just trying to make the table readable in the first report.

[ahouseholder]

Updated issue title to reflect the above consensus.