Handle the presence of attributes or the public key within a private key

[str4d]

RFC 8410 section 7 specifies that a private key may contain attributes, or its corresponding public key. These are marked as OPTIONAL, which per BCP 14 means that we

MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality.

I interpret this as meaning we need to handle their potential presence when decoding a key:

• If attributes are present, we skip over them.
• If a public key is present, we verify that it matches the private key.

I don't interpret this as meaning we need to support storing them (if provided), or that getEncoded() MUST return the same encoding as was originally passed in (in fact, it explicitly disclaims this in order to migrate keys encoded using the older draft specification back from when this library was first written). In other words, getEncoded() would return the canonical minimal encoding as already-implemented.