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