Future omnibor-cli use case: creating wrappers to OmniBOR-ify builds that don't support OmniBOR natively.

[alilleybrinker]

One of the challenges of OmniBOR adoption is that optimally we want OmniBOR data to be produced automatically by the build tools people already use. Whether it's a code generator, a compiler, a linker, or something else, if you're creating a software artifact we'd like to also create and then be prepared to distribute Input Manifests for that artifact and its dependencies. However, we also don't want to have to wait for large numbers of independent open and closed source projects to adopt OmniBOR and start producing OmniBOR data. To that end, a common pattern we'll likely end up seeing would be to wrap existing tools so that we can gather the necessary data to produce Input Manifests without modifying the original tools. Some tools (like cargo/rustc) even support this kind of "wrapper" mechanism natively. The omnibor-cli could be part of making it easy to produce these wrapper; they could call out to the CLI to run the necessary commands to produce identifiers and manifests.

This is just describing a use case, I haven't yet worked out the specific API.