feat: add GitLab CI provider support

[cgroschupp]

Fixes: #52

openpubkey/verifier.NewFromMany stores provider verifiers in a map keyed by issuer:

https://github.com/openpubkey/openpubkey/blob/main/verifier/verifier.go#L126

Because of that, a verifier list cannot contain two providers with the same issuer. If two entries use the same issuer, NewFromMany rejects them as duplicates.

This becomes a problem for GitLab because both normal interactive GitLab login and GitLab CI tokens use the same issuer:

https://gitlab.com

but they require different verification behavior:

• normal GitLab login uses the standard GitLab/OIDC verifier
• GitLab CI uses OpenPubkey's GitLab CI verifier for GQ-bound (GQ256) tokens

A server may need to allow both at the same time, for example:

https://gitlab.com 8d8b7024572c7fd501f64374dec6bba37096783dfcd792b3988104be08cb6923 24h
https://gitlab.com OPENPUBKEY-PKTOKEN:ssh-deploy-prod 24h

Both entries have the same issuer, but represent different accepted audiences/token types.

[EthanHeilman]

@cgroschupp

Lets say you have an OPKSSH server that accepts both GitLab Login ID Tokens and GitLab-CI ID Tokens. How do you tell the tokens apart? If you use the presence of GQ Signatures to tell them apart, an attacker could simply turn a captured GitLab Login ID Token into a GQ-signed Gitlab-CI ID Tokens and in so doing bind the attackers public key.