Add KMS signer support for AWS, GCP, Azure, and file-based backends

[SequeI]

Summary

This commit adds support for signing models using Key Management Service (KMS) providers through KMS URIs. The implementation follows the same pattern as the existing PKCS11 signer, providing a consistent interface for raw signer instantiations.

The KMS signer supports multiple cloud providers:

• AWS KMS: kms://aws/<key-id/key-arn>?region=<region>
• Google Cloud KMS: kms://gcp/<project>/<location>/<keyring>/<key>
• Azure Key Vault: kms://azure/<vault-url>/<key-name>?version=<version>
• File backend: kms://file/<path> (for local testing)

Closes #203

Tested file and AWS file backends, did not test Azure or GCP as I do not have an account. It should more or less be correct for those KMS backends though (minor fixes perhaps)

Moved some testing resources and the check EC curve functions to not duplicate

Added tests for KMS

Checklist

• All commits are signed-off, using DCO
• All new code has docstrings and type annotations
• All new code is covered by tests. Aim for at least 90% coverage. CI is configured to highlight lines not covered by tests.
• Public facing changes are paired with documentation changes
• Release note has been added to CHANGELOG.md if needed

[Hayden-IO]

Quick drive-by comment - Are there concrete use cases for the chosen KMS providers, or is this to mirror what's available in the Go libraries? We've had some challenges supporting Azure and AWS because the public infrastructure doesn't use these, and we have no test infrastructure to verify functionality. If no one is asking for these, I'd limit which KMS providers are supported.

[mihaimaruseac]

+1, let's only add the support here when there is a significant need for this.

It's for the same reason why #148 is still open, but because we haven't yet seen an actual demand to hash models while they are on remote blob storage we did not spend cycles to implement it.

[mihaimaruseac]

Confirmed that there is a usecase for this

[SequeI]

@mihaimaruseac Which provider is the use case for?

IMO, I can revise this PR to add support for that specific provider first, then when need arises we can increase KMS provider options.

[mihaimaruseac]

Yesterday at the OMS meeting @ralphbean said that there is a need for this PR

[Hayden-IO]

But for all KMS providers? If you don't have a good way to test support across all of these ecosystems, I would advise against proactively adding all of them.