NULL parameter is breaking the spec

Your code at https://github.com/indygreg/cryptography-rs/blob/c078199a1b86191e19a53993691850769e7748d2/x509-certificate/src/rfc5280.rs#L73 states:

```
// parameters is strictly OPTIONAL, which means we can omit it completely.
// However, it is common to see this field encoded as NULL and some
// parsers seem to insist the NULL be there or else they refuse to
// parse the ASN.1. So we ensure this field is always set.
```

That is absolutely incorrect. According to the x509 specs https://datatracker.ietf.org/doc/html/rfc8410

> In this document, we define four new OIDs for identifying the
different curve/algorithm pairs: the curves being curve25519 and
curve448 and the algorithms being ECDH and EdDSA in pure mode. For
all of the OIDs, the parameters MUST be absent.

Note, ***MUST be absent***. If a parser breaks on valid certificates, then the parser needs to be fixed, not the certificate generator broken.

OpenSSL for example will flat out reject your certs with:

```
80CC200502000000:error:03000072:digital envelope routines:X509_PUBKEY_get0:decode error:crypto/x509/x_pubkey.c:464:
```

Inspect x509-certificate/src/rfc5280.rs around line 73 and compare the SubjectPublicKeyInfo encoding with RFC 8410. Verify that the affected EdDSA or ECDH certificates omit the parameters field and test that OpenSSL accepts the generated certificate without the reported X509_PUBKEY_get0 decode error.

Written by the indexing model from the issue text.