Enforce Vulnerability::StateTransitions as an Audit Trail record

Fix dismissal_reason updates (!130509 - merged) • Gregory Havenga • 16.4 enabled the modification of an existing state transition dismissal reason, whereas other Security Insights code will prefer to create a new state transition when a user opts to modify the dismissal_reason.

The reason for this disparity was that there was some intention that state transitions were to be auditable objects that should not be modifiable, but it seems in our code we aren't overly inclined to hold fast to this concept. After discussing this further we should rather not change existing VST records ever, but instead make a new record to reflect any changes.

The API's should be updated to reflect the chosen paradigm, and we should try add some kind of rules to the code to prevent update operations on VST. (Deletion is fine as that will be part of the retention policy)