Add serialization of private key material (`KeyExporter`)

# Requirement

Enable re-instantiation of `BearerDid` instances from serialized private key material, which implies we must support serializing private key material.

### Use Cases

#### Test Suites

We want to rely on deterministic test vectors (composed of static data, some of which is encrypted or signed by private key material) which are freely interoperable across languages.

#### Workaround for Secure Enclave & HSM Limitations

(@mistermoe help me out here, fill gaps and correct me where I'm wrong)

There are no guarantees that all key management solutions will support our set of cryptographic requirements. For example, Ed25519 isn't supported in AWS KMS. In such a case, we must workaround this by serializing the private key material, storing it in a secure environment (ex. AWS Secrets Manager), deserializing the private key material at runtime, and relying on memory safety for security requirements. In other words, we can't assume the usage of a secure enclave or HSM solution by the application.

#### Others???

If there are other use cases for the serialization of private key material, then please comment such use cases below!

# Solution

We can agree for certain to add a `KeyExporter` trait to the `keys` crate (inspiration can be taken from `KeyImporter` #204).

The contested matter is whether or not to first-class conceptualize a `PortableDid` type struct. The inclusion of the `PortableDid` type struct gives us an explicit data structure which represents a fully self-contained serialized instance of a `BearerDid`. The alternative would be to rely on the calling code (the app developer) to maintain the state associating the serialized private key(s) with the given DID.

It's not obvious to me that it's beneficial for us, at this time, to introduce a `PortableDid` at the rust core layer. It's not obvious it'll assist us with bindings. There's also a layer of complexity here with regards to #142 and if we decide to full-commit to JWK as the sole key representation or not.

For the sake of this ticket, I would recommend we do not introduce the `PortableDid` concept. With recognition we _may_ if it becomes abundantly clear to do so. I'm open to challenging this though. By adding the `KeyExporter`, at a minimum, we _enable_ the concept of a `PortableDid` even though, without the implementation, we don't _provide_ it.

This ticket is relevant to https://github.com/TBD54566975/web5-spec/issues/112#issuecomment-1924691567

---

All of the below web5 SDKs have `PortableDid` as a dedicated type struct.

- `web5-js` https://github.com/TBD54566975/web5-js/blob/main/packages/dids/src/types/portable-did.ts
- `web5-kt` https://github.com/TBD54566975/web5-kt/blob/main/dids/src/main/kotlin/web5/sdk/dids/did/PortableDid.kt
- `web5-swift` https://github.com/TBD54566975/web5-swift/blob/main/Sources/Web5/Dids/PortableDID.swift
- `web5-go` https://github.com/TBD54566975/web5-go/blob/main/dids/did/portabledid.go
- `web5-dart` https://github.com/TBD54566975/web5-dart/blob/main/packages/web5/lib/src/dids/portable_did.dart