split the AWS KMS keyring specification

[mattsb42-aws]

We originally envisioned the AWS KMS keyring as a single thing because it interacts with a single service. However, as we have refined the defined behavior over time, what we have really come away with is two keyrings that each have fundamentally different behavior: the standard KMS keyring and the KMS discovery keyring. I think that we should split the specification into two documents to accurately reflect this.

KMS keyring

The KMS keyring can be configured with a generator key ID and additional key IDs, and behaves exactly as if you were to have a multi-keyring composed of "single-CMK KMS keyrings". (side note: this is actually how the Python KMS keyring is implemented internally). On encrypt, every CMK MUST succeed and on decrypt it MUST only attempt to decrypt EDKs from the specified CMKs.

KMS discovery keyring

The KMS discovery keyring does something completely different: on encrypt it does nothing, while on decrypt it attempts to decrypt any aws-kms EDK for which the client supplier will supply a client.

meta-interface

An important thing to note here is that the interface for creating KMS keyrings does not need to change.

[acioc]

for which the client supplier will supply a client - I wanted to link this back to #15

It would be great to have some specifications around what client suppliers we expect the ESDKs to all support. Anyone using the ESDK should be able to write their own client supplier, but the ones we provide by default in each ESDK should be noted somewhere in the specification as well.

[acioc]

Closing in favor of #165