Proposed Structure for KeyMetaData in DelegatedTransactionSigner

[sappenin]

v3 of this library introduces a revamped transaction signing and key-management system to support both in-memory private keys (i.e., private keys that live in the JVM, maybe for learning, prototyping code and/or Android clients perhaps) and a set of sibling interfaces meant to provide delegated access to private-key material that does not live in the JVM that is running xrpl4j (e.g., a "handle" to a key in an HSM).

The current code has this contract -- DelegatedTransactionSigner -- which relies upon an object called Keymetadata to describe the location of a key that can be used for signing.

The intent with this interface is that it should be possible to describe the location of any type of private key -- e.g., all the metadata needed to sign a transaction using a key in GCP's Cloud HSM.

That said, is this the best/most-ideal object/interface contract? Will it work for all situations? Is there an alternative design that we should consider?

For example, we might imagine a polymorphic version of Keymetadata sort of like we did with ServerInfo.