Re-implement replaced_by functionality from #130

[evankanderson]

After the merge of the governance part of #130, the second half (creating a mechanism for tracking criteria renaming) was still pending (and the script had been re-arranged).

This PR does the following:

• Re-introduces the replaced_by field for renumbering / retiring criteria (currently a single rule, but we could make it a list if that makes more sense)
• A bit of cleanup:
  • Return an errors.Join() of detected errors, rather than log.Printf() each error and then returning a new "errors occurred" error. This may help if we use the code as a library later.
  • Use slices.Contains() rather than writing our own contains method.
  • Sort the criteria in each category by name.

[SecurityCRob]

I approve the idea, but defer to our development experts on the execution

[funnelfiasco]

This doesn't appear to quite work. I added replaced_by: OSPS-XY-01 to an entry and it was not rendered.

But before we try to fix that, I'm thinking about how this would actually be used. If we adopt something like the process I proposed in #116, this field doesn't need to be rendered, it's just a note in the yaml for future reference. We should probably settle on our maintenance process before we start implementing it.

[eddie-knight]

let's address the functionality comment from @funnelfiasco — I'm happy with the intent here though

[evankanderson]

This doesn't appear to quite work. I added replaced_by: OSPS-XY-01 to an entry and it was not rendered.

I added the following to the criteria in the OSPS-DO.yaml file, and it seemed to work, though the formatting was a bit funky (I've since fixed it). Note that you need to reference a valid other rule, or the build breaks (it checks the references).

  - id: OSPS-DO-01
    replaced_by: OSPS-GV-03

This now renders as:

But before we try to fix that, I'm thinking about how this would actually be used. If we adopt something like the process I proposed in #116, this field doesn't need to be rendered, it's just a note in the yaml for future reference. We should probably settle on our maintenance process before we start implementing it.

My thought was that people may also either have links to "latest" or simply search the latest for these strings, so it would be handy to have a 2-line link for folks.

(This PR should now be ready, if we decide we want to be able to track this -- we can always iterate on the template rendering later if desired.)