Expose DSSE verification in the CLI

[woodruffw]

Per #628, we now have DSSE signing and verifying support in the APIs. We haven't, however, exposed it via the CLI, for a few reasons:

1. DSSE verification isn't conceptually tied to an independent input in the way that our current sigstore verify ... commands expect: with DSSE the input is embedded in the bundle, cryptographically verified, and then returned for subsequent policy verification. If we want to expose DSSE verification in the CLI, we'll need to decide whether to accomodate that pattern or whether to restrict it (e.g. by requiring a file to verify against, which must either fully match the payload, or must match the in-toto statement's subject digest, or something else).
2. It isn't 100% clear to me if/how we should return the verified DSSE payload: it might be binary, an in-toto statement, or something else. Maybe the CLI could only support in-toto JSON payloads.
3. We need to figure out how to communicate the DSSE verification model to users: sigstore verify is conceptually simple ("the file has a valid signature from some identity"), while DSSE introduces the idea of "a bundle is valid if the valid payload within it matches some policy." This might confuse users who conflate "the bundle has a valid signature" with "I don't need to validate the data within the bundle."

Minimally, we could probably get away with leaving sigstore verify the way it is, but allowing a limited subset of DSSE bundles within it: ones that have an in-toto payload, which we could then verify the statement within against the digest of the independent input. This would probably cover >90% of use cases, e.g. verifying bundles from GitHub's attestation beta.

[woodruffw]

Revisiting: I think we can carve out a limited version of DSSE verification in the CLI that'll be compatible with the pre-existing CLI subcommands.

In particular: sigstore verify identity foo.txt will behave like it currently does, but will also verify DSSE entries so long as their subject matches foo.txt's hash. This is consistent with what gh attestation verify does.

CCing @di for visibility 🙂