Interoperability issue: PEM encoding for Ed25519 private keys

I would like to take the certificates managed by Caddy and use them under other software. However, the way CertMagic generates PEM files for Ed25519 keys is incompatible with modern versions of OpenSSL and this can be fixed with minimal changes.

I found the relevant line of code causing this issue, and it means that any Ed25519 private key file generated by CertMagic will have this issue: https://github.com/caddyserver/certmagic/blob/cf6f57dc2126cf91f2b582c63a8668c6bf3b785d/crypto.go#L69

Essentially, this generates PEM files for private keys of the form:

-----BEGIN ED25519 PRIVATE KEY-----
(data)
-----END ED25519 PRIVATE KEY-----

Note that CertMagic also outputs similar PEM files for ECDSA and RSA keys, however, the outputted PEM looks like:

-----BEGIN RSA PRIVATE KEY-----
(data)
-----END RSA PRIVATE KEY-----

or:

-----BEGIN EC PRIVATE KEY-----
(data)
-----END EC PRIVATE KEY-----

If you check the OpenSSL documentation, both of the above are acceptable values, but not the one for Ed25519: https://docs.openssl.org/3.0/man1/openssl-format-options/#format-option-arguments

(Since even the various OpenSSL forks try to maintain compatibility with OpenSSL, this is probably the documentation we should be following. LibreSSL appears to also share this problem, but I didn't check any other forks.)

Note that in all cases, the generated PEM includes the key type in the encoded data, and so, putting the key type in the header is technically redundant. OpenSSL actually accounts for this and allows just the following:

-----BEGIN PRIVATE KEY-----
(data)
-----END PRIVATE KEY-----

This feels like the appropriate way to solve the problem, since for example, the "public" key is just listed as CERTIFICATE, and the type isn't specified in the header. I'll submit a PR soon with this recommended change.

Read crypto.go at line 69, where CertMagic generates the Ed25519 private-key PEM. Verify the expected PEM format against the OpenSSL documentation and check the existing key-generation behavior for RSA and ECDSA. Done means Ed25519 keys can be consumed by modern OpenSSL while existing key handling remains compatible.