Better handling of non-sensical PEM encrypted exports

[timw]

Doing some "all combinations" testing for a CA tool that included export to various PEM flavours, I ran into an inconsistency in the BC encrypted PEM export for (non RSA/EC) private keys.

Short story:

• If you export a (non RSA or EC) private key (e.g. EDDSA) using a MiscPEMGenerator with a PEMEncryptor provided, it encodes a PRIVATE KEY block containing the PrivateKeyInfo structure, then encrypts the contents using the RFC 1421 "traditional" encryption.
• On import via a PEMParser, this is detected as an unencrypted PKCS8 encoded private key entry, which then fails to decode in various entertaining ways since the key data is encrypted.

Given it's unlikely that the "traditional" PEM encoding will ever be updated to support newer key types like EDDSA and XDH (openssl 3.0 stoically refuses to produce a traditional PEM encoding of EDDSA keys), I can't see this is as a bug (i.e. there's no point actually support traditional encrypted variants of these keys), but I wonder if we could tighten up the implementation a bit to clarify that.

e.g. in MiscPEMGenerator could simply disallow a PRIVATE KEY export with a PEMEncryptor and PrivateKeyParser could potentially sanity check for the traditional encryption PEM headers (although if the first change was made, this would be an unlikely occurrence).