A private key converted into a 'KeyPair' can be exported in the
conventional DNS format.  This is an important step in implementing
'ldns-keygen' using 'domain'.  It is up to the implementation modules
to provide conversion to and from 'KeyPair'; some impls (e.g. for HSMs)
won't support it at all.

'Sign' is a more generic version of 'sign::key::SigningKey' that does
not provide public key information.  It does not try to abstract over
all the functionality of a keypair, since that can depend on the
underlying cryptographic implementation.

There are probably lots of bugs in this implementation, I'll add some
tests soon.

Also fixes 'cargo clippy' issues, particularly with the MSRV.

I'm going to add a corresponding 'PublicKey' type, at which point it
becomes important to differentiate from the generic representations and
actual cryptographic implementations.

Key generation, for now, will only be provided by the OpenSSL backend
(coming soon).  However, generic keys (for RSA/SHA-256 or Ed25519) can
be imported into the Ring backend and used freely.

The OpenSSL backend supports import from and export to generic secret
keys, making the formatting and parsing machinery for them usable.  The
next step is to implement generation of keys.

There were bugs in the Base64 encoding/decoding that are not worth
trying to debug; there's a perfectly usable Base64 implementation in
the crate already.

I had to swap out the RSA key since 'ring' found it to be too small.

- RSA signatures were being made with an unspecified padding scheme.
- ECDSA signatures were being output in ASN.1 DER format, instead of
  the fixed-size format required by DNSSEC (and output by 'ring').
- Tests for signature failures are now added for both backends.

Most functions have been renamed.  The public key types have been moved
to the 'validate' module (which 'sign' now depends on), and they have
been outfitted with conversions (e.g. to and from DNSKEY records).

Importing a generic key into an OpenSSL or Ring key now requires the
public key to also be available.  In both implementations, the pair are
checked for consistency -- this ensures that both are uncorrupted and
that keys have not been mixed up.  This also allows the Ring backend to
support ECDSA keys (although key generation is still difficult).

The 'PublicKey' and 'PrivateKey' enums now store their array data in
'Box'.  This has two benefits: it is easier to securely manage memory
on the heap (since the compiler will not copy it around the stack); and
the smaller sizes of the types is beneficial (although negligibly) to
performance.

This makes space for higher-level interfaces which track DNSKEY flags
information (and possibly key rollover information).

Tests would spuriously fail when generated keys were only 31 bytes in
size.

This is more efficient than allocating a DNSKEY record and computing
the key tag there.

The test keys have been rotated and replaced with KSKs since they have
associated DS records I can verify digests against.  I also expanded
Ring's testing to include ECDSA keys.  The validate module tests SHA-1
keys as well, which aren't supported by 'sign'.

Public keys in the BIND format can now have multiple lines (even with
comments).  Keys can also be directly written into the BIND format and
round-trips to and from the BIND format are now tested.

The 'openssl' and 'ring' modules should now follow the contributing
guidelines regarding module layout and formatting.

This is useful for abstracting over OpenSSL and Ring, so that Ring can
be used whenever possible while OpenSSL is used as a fallback.  This is
useful for clients that just wish to support everything.

The 'Dnskey' impl of 'fmt::Display' was no longer accurate to the zone
file format because 'SecAlg' now prints '<code>(<mnemonic>)'.

It's a bit hacky because it relies on specific byte indices within the
generated PKCS8 documents (internally, Ring basically just concatenates
bytes to form the documents, and we use the same indices).  However,
any change to the document format should be caught by the tests here.

Now that Ring and OpenSSL support all mandatory algorithms, OpenSSL is
no longer required in order to provide signing functionality.

For consistency with the upcoming 'PublicKeyBytes'.