Introduce "cyclonedx rename-entity" command (bis)

[jimklimov]

Re-introduce it in a sense: this was posted earlier as PR #346 and still relies on CycloneDX/cyclonedx-dotnet-library#245 for the bulk of work (BomEntity base-class and interface family, etc.) and CycloneDX/cyclonedx-dotnet-library#256 for metadata update of the output document.

The earlier PR did not fail any formal tests (maybe should have added some, to ensure the contemporary library has the features exposed by it), so was prematurely merged and then reverted back by commit 91cf6c6 before cyclonedx-cli v0.26.0 release.

[mtsfoni]

basically this is supposed to change a known bom-ref to another bom-ref?

I wrote this a tool cdx-enrich (will change the name to cdx-edit soon), I don't even use it myself yes, but this could be a good functionality for that tool as well. It can also take a list of operations, so if you plan to overwrite known bom-refs in a pipeline after creating a bom, this could work pretty good.

Thoughts?

[jimklimov]

FYI: This PR is part of a series I've opened 3 years ago, and stalled in review for whatever reasons including the under-the-hood use of reflection to implement inspection of arbitrary BOM entities to merge them, including the ones still open at this time:

• Json/Validator: add findNamedElements() to detect duplicate "bom-ref" definitions cyclonedx-dotnet-library#240
• FlatMerge should deduplicate "equivalent" entries and squash their data cyclonedx-dotnet-library#245
• Bom: initialize its own metadata cyclonedx-dotnet-library#256
• Introduce "cyclonedx rename-entity" command (bis) #396 (revised re-open of Introduce "cyclonedx rename-entity" command #346)
• MergeCommand: use Bom.BomMetadataUpdate()… #340
• MergeCommand: add options to --validate-output(-relaxed) … #335
• MergeCommand.cs: ensure a timestamp and use new cyclonedx-dotnet-library features… #334
• Add "merge --input-file-list NAME ..." as a way to exceed CLI limits #328

I (and my dayjob's budget) have recently employed Claude AI to pick up where I left long ago, and rewrite those changes in idiomatic C#, rebased over current upstream achievements.

After some internal dev-testing shows that this rewrite is successful, I hope these old PRs will be supplanted by a new series with new technological base and same or better feature set as what I was stuck with using (slowly bit-rotting over the years). Hopefully the new set of PRs would be less questionable for an upstream merge :)

I'll add this note to all impacted PRs listed above.