Evaluate options to limit dependencies or sandbox execution of cosign in glgo

ON HOLD: The new proposal is to add the Cosign binary to GitLab distributions (#556801 (closed) and #556802 (closed)). We keep that issue in case we face significant challenges while pursing that new proposal. If things go well, we'll close that issue, and mark it as won't do/no longer relevant.

The current proposal for SLSA attestation generation and signing is to import cosign into the glgo service and interact with it via an API.

There are some concerns related to the number of dependencies required to import cosign. The purpose of this issue is to evaluate options available to limit the surface area of dependencies required to make a functional API that can be used in the SLSA workflow. Some potential options to evaluate are:

• Limit indirect dependencies to only what is required for the needed functions
• Evaluate sigstore-go as a potential alternative
• Evaluate the possibility of adding the cosign binary to the base image used by glgo
• Evaluate any other strategies or tools for sandboxing the usage of cosign in the glgo API

The output of this issue should be an written summary of the options evaluated with pros/cons of each, as well as proposed direction considering the tradeoffs.