Remove/adjust 2 Mozilla P-521 lints

[clintwilson]

e_mp_ecdsa_pub_key_encoding_correct and e_mp_ecdsa_signature_encoding_correct are (I believe) written based on the Mozilla Root Program Policy prohibiting P-521 keys, but this policy does not actually currently prohibit P-521 per Section 5.1:

The following curves are not prohibited, but are not currently supported: P-521, Curve25519, and Curve448.

Unfortunately this does somewhat conflict with the statement preceding this:

Root certificates in our root store, and any certificate that chains up to them, MUST use only algorithms and key sizes from the following set

However, based on discussions with Mozilla and their Issue 281 it seems absolutely clear that the intent is not to restrict certificates using P-521 curve from existing. Thus, I believe the above referenced lints can be removed -- however if they're doing more than checking for compliance with this section of the Mozilla policy, then they may instead warrant adjustment rather than removal.

Related Issues: #354 #355 #358

[christopher-henderson]

Thank you @clintwilson!

I suppose that the logic currently is...

if key in allowed {
    return PASS
} else {
    return FAIL
}

...when it should be a bit more nuanced and warn that you are using keys that are allowed, but that may not work...

if key in allowed {
    return PASS
} else if key in unsupported {
    return WARN
} else {
    return FAIL
}

Do you believe that this would be a more accurate lint?

[digirenpeter]

To revisit this issue @christopher-henderson, it looks like Mozilla has updated the Root Store policy to just allow for P-521
SPKI

When ECDSA keys are encoded in a SubjectPublicKeyInfo structure, the algorithm field MUST be one of the following, as specified by [RFC 5480, Section 2.1.1](https://datatracker.ietf.org/doc/html/rfc5480#section-2.1.1):

the encoded AlgorithmIdentifier for a P-256 key MUST match the following hex-encoded 
bytes: 301306072a8648ce3d020106082a8648ce3d030107;

the encoded AlgorithmIdentifier for a P-384 key MUST match the following hex-encoded 
bytes: 301006072a8648ce3d020106052b81040022; or

the encoded AlgorithmIdentifier for a P-521 key MUST match the following hex-encoded 
bytes: 301006072a8648ce3d020106052b81040023.

The above encodings consist of an ecPublicKey OID (1.2.840.10045.2.1) with a named curve parameter of the corresponding curve OID. Certificates MUST NOT use the implicit or specified curve forms.

SignatureAlgorithm

When a root or intermediate certificate's ECDSA key is used to produce a signature, only the following algorithms MAY be used, and with the following encoding requirements:

if the signing key is P-256, the signature MUST use ECDSA with SHA-256. The encoded AlgorithmIdentifier MUST match 
the following hex-encoded bytes: 300a06082a8648ce3d040302.

if the signing key is P-384, the signature MUST use ECDSA with SHA-384. The encoded AlgorithmIdentifier MUST match 
the following hex-encoded bytes: 300a06082a8648ce3d040303.

if the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the AlgorithmIdentifier MUST 
be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040304.

The above encodings consist of the corresponding OID with the parameters field omitted, as specified by [RFC 5758, Section 3.2](https://datatracker.ietf.org/doc/html/rfc5758#section-3.2). 
Certificates MUST NOT include a NULL parameter. Note this differs from RSASSA-PKCS1-v1_5, which includes an explicit NULL

So I opened a PR updating these two lints.
#950