Support EdDSA account keys

Note: This is not an issue for supporting EdDSA keys in subscriber certificates, or offering an EdDSA intermediate.

See this community forum thread for more background.

It only makes sense to add this to the V2 API. The V1 API is EOL and its JWS/JWK verification is pretty haggard.

At a high-level to support EdDSA account keys we will need to:

• - Add EdDSA support to wfe2/verify.go, notably sigAlgorithmForKey.
• - Split goodkey somehow to support vetting account keys differently than CSR keys.
• - Add EdDSA support to goodkey.

This work would need to be done with a particular eye towards anywhere we might need to verify EdDSA public key parameters above and beyond what may be done by go-jose. Similarly it may be prudent to check what linting zlint,certlint, etc perform for EdDSA subscriber keys and verify that we have represented the same checks in go-jose or goodkey.

Splitting goodkey to support different rules depending on the context of the public key stands out as something somewhat risky. We need to ensure there is minimal chance that the RA or CA will end up vetting a CSR key as if it were an account key, leading to misissuance of certificates.

Start with wfe2/verify.go and sigAlgorithmForKey, then trace goodkey's account-key and CSR-key validation paths. Review the relevant go-jose behavior and compare EdDSA parameter checks with zlint and certlint expectations. Done means V2 account keys support EdDSA while account-key and CSR-key vetting remain safely distinct.