Bom: initialize its own metadata

[jimklimov]

This PR is yet another part of my larger proposal of Merge ability changes stacked in the PR queue.

It adds some utility methods to Bom class, so it can be in charge of initializing a (usually new) Bom object into a usefully populated one, e.g. the merge result to pile other Bom's into, while being the authoritative location to know and care about the class and data structure involved - well in OOP style.

These methods allow the Bom object to initialize:

• a Metadata object (if null);
• a collection of Metadata/Tools (now updated to match recent changes in upstream code of the library with a ToolChoices layer) pre-populated with the current version of the cyclonedx-dotnet-library and if possible to discover - its consumer like the cyclonedx-cli tool;
• a timestamp (now);
• either a new serial number (new UUIDv4) and set Version=1 if this is a new document (or if explicitly requested by method argument), or increment the Version field if it is a re-iteration of an existing document.

Library consumers which modify these fields directly (e.g. MergeCommand.cs in cyclonedx-cli) would benefit from being updated accordingly; a PR to this effect will be posted shortly.

Calls to these methods were added to HierarchicalMerge() and FlatMerge(Boms, ...) methods, to pre-populate the result object into which merged information would land, since after any processing we conceptually yield a new document.

Note that it would be pedantically prudent to also do this in FlatMerge(Bom, Bom) method which does most of the actual merging work - however, it does so in a loop (called from FlatMerge(Boms, ...)) and in current Merge.cs codebase would just waste CPU time on detection or generation of needed information just to forget it with the next cycle. Still, it would be "correct" to populate this information for the benefit of (theoretically possible, not seen yet) "other consumers" who would only call this method directly, and not know/care about populating those fields on their own, whether "manually" or by using the Bom methods introduced here on the object that pops out from the FlatMerge() call. I did not pursue this corner case here, because it is addressed differently (with an API change to pass toggles whether to do or skip such pre-init) in the larger solution for merge ability improvements.

As it happens, this PR also fixes an issue reported earlier:
Closes: #183

[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 #240
• FlatMerge should deduplicate "equivalent" entries and squash their data #245
• Bom: initialize its own metadata #256
• Introduce "cyclonedx rename-entity" command (bis) cyclonedx-cli#396 (revised re-open of Introduce "cyclonedx rename-entity" command cyclonedx-cli#346)
• MergeCommand: use Bom.BomMetadataUpdate()… cyclonedx-cli#340
• MergeCommand: add options to --validate-output(-relaxed) … cyclonedx-cli#335
• MergeCommand.cs: ensure a timestamp and use new cyclonedx-dotnet-library features… cyclonedx-cli#334
• Add "merge --input-file-list NAME ..." as a way to exceed CLI limits cyclonedx-cli#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.

[jimklimov]

Superseded by #446, which bundles Bom.BomMetadataUpdate()/ReferThisToolkit() together with BomRefWalker/RenameRef (same Bom.cs area, developed together). Closing this in favor of #446.