Prototype: Plugin keyless verification

[wata727]

See #1351

Recently, the new sigstore-go was released by the Sigstore community. This is a long-awaited library that provides a Go API for keyless verification, which is what was ultimately needed for TFLint's plugin mechanism.

This PR is a prototype that uses sigstore-go for plugin verification. A stable version of sigstore-go has not yet been released, so this implementation is subject to change in the future. The goal here is a proof of concept.

Once this feature is merged, we will be freed from managing GPG keys embedded in TFLint, and third-party developers can safely provide plugin installations without declaring a signing_key.

To understand this change, you need to understand Sigstore's underlying technology. The following documentation may be helpful.

• https://www.sigstore.dev/how-it-works
• https://docs.sigstore.dev/about/overview/
• https://docs.sigstore.dev/about/security/
• https://docs.sigstore.dev/about/threat-model/
• https://docs.sigstore.dev/verifying/timestamps/

Please note that sigstore-go primarily support Sigstore bundles. On the other hand, the TFLint plugin is signed with Cosign, so the common example of sigstore-go is not available out of the box. This may be improved in a future sigstore-go version. This prototype solves this problem by implementing its own entity to satisfy the SignedEntity interface.

Specifically, what keyless verification does is as follows:

1. Verify SET (Signed Entity Timestamp) in VerifyObserverTimestamps. The SET is embedded in the transparency log, which can be retrieved from Rekor based on the artifact's SHA-256. The SET and T logs cannot be tampered with because they are verified using Rekor's root public key.
2. Verify certificate chain in VerifyLeafCertificate. This allows you to verify that the certificate passed was issued by Fulcio using Fulcio's root public key. At the same time, it verifies that the certificate was valid in SET and ensures that the leaked and revoked short-lived certificate has not been reused.
3. Verify SCT (Signed Certificate Timestamp) in VerifySignedCertificateTimestamp. This ensures that the certificate was recorded in CT log servers. The SCT is verified using the CT log server's root public key, so it cannot be tampered with.
4. Verify signature in VerifySignatureWithArtifact. Since the certificate's public key is guaranteed in previous steps, we use it to verify that the artifact is signed.
5. Verify certificate identity in certificateIdentities.Verify. Since anyone can issue a certificate, the final step is to verify the certificate's identity. The identity is embedded in a certificate signed by Fulcio, so there is no room for tampering.

Please read the comments for details.