sign SBOMs through cosign tool right after generated it through bom tool

#### What would you like to be added:

We talked about a bit of generating/signing process of SBOMs on the `sigstore` Slack channel. In this talk @SantiagoTorres and @nadgowdas made a really valuable comment:

> nadgowdas: In general, I think signing should be inherent to the SBOM generation process. If you have one task that generates SBOM, stores it in shared space, and other task signs it, then we are federating the trust across tasks. Maybe, the SBOM generation tool as a part of generation should automatically sign the SBOM

> SantiagoTorres: Agreed, there's a slight time window in which it could have tampered. It shouldn't be too hard to tighten the distance between generation and signing with the available tooling though

👉 https://sigstore.slack.com/archives/C01D0PA9QKF/p1632149577045600

There is a tool called [Syft](https://github.com/anchore/syft) created by the Anchore team. They also started to work for the direct signing of SBOMs right after generating them. Thanks to @luhring

👉 https://github.com/anchore/syft/issues/510

So, I'm proposing the same one for the `bom` CLI, we can use cosign as a library to sign SBOM documents right after generated them through the `bom` CLI because cosign has support for storing SBOMs on OCI Registry and also signing them.

cc: @Dentrax @dlorenc @erkanzileli

Start with the bom CLI's SBOM generation flow and the cosign library, then compare Syft's direct-signing work referenced in the issue. Done means bom generates an SBOM and signs it immediately, with cosign's SBOM storage and signing support available through the proposed workflow.

Written by the indexing model from the issue text.