Add tests for bundle support

[tetsuo-cpp]

Once #51 is done, we should look at exercising bundle support. We should write some basic unit tests exercising that bundles are created correctly and can be verified with the same client.

[loosebazooka]

How are we specifying bundles? Currently the cli interface (interface interface?) in sigstore-java allows specifying either sig/cert output files or a bundle output file. But I think from our last slack discussion, it wasn't clear if the python cli could enforce those constraints?

[tetsuo-cpp]

@tnytown will figure that out as part of #51 first. But I think we can/should make the spec match sigstore-java's CLI behaviour.

In the current spec, there's an emphasis on guaranteeing that flags are in order and are non-optional, etc for ease of argument parsing. I think we should mostly get rid of that emphasis and allow:

<client> verify --signature foo.sig --certificate foo.sig foo.txt

or

<client> verify --bundle foo.sigstore too.txt

That way, the CLI isn't only useful for conformance testing but is more ergonomic for general use like what you're using it for with sigstore-java. Let me know whether that answers your question.

[tnytown]

Just got to this. I slightly prefer separating the two different flows (sig+crt vs. bundle) into different subcommands, as this makes it clear to confused users which flags are valid together. In this scenario, --bundle would only be valid on the [sign|verify]-bundle subcommands and --signature + --certificate would only be valid on [sign|verify] subcommands. Regardless, I'm not sure if this distinction is useful for the conformance testing interface and I'd be happy to defer to the current sigstore-java / sigstore-python interface.

[woodruffw]

#66 contains some concrete examples of test cases we'll want to exercise with this functionality.