Reduce redundancies in keyring specifications

[lavaleri]

One piece of feedback from team review is that description of how values for fields within the constructed EDKs are calculated (specifically the ciphertext) should exist as part of the EDK structure. The OnEncrypt and OnDecrypt calls can then rely on that structure, and avoid having very similar sets of (mostly) repeated requirements.

Acceptance criteria:
-reword the raw AES Keyring spec to move encryption specific requirements into the structure
-reword the raw RAW Keyring spec to move encryption specific requirements into the structure
-reword the KMS Keyring spec to move encryption specific requirements into the structure

[lavaleri]

After inspecting this issue again and the current state of the spec, there is no action to take here. The EDK in structures.md defines exactly the requirements for an EDK, and the keyrings define more specifically what that keyring MUST use for those fields.

• For the ciphertext, the value used is calculated differently for each keyring.
• For the key provider id, the raw keyrings derive this from their key namespace (which is not a required property of a keyring). The KMS keyring always uses "aws-kms"
• For the key provider info, this depends totally on the keyring implementation. The Raw AES keyring uses specific serialized info, the raw RSA keyring uses it's keyname, and KSM uses th keyID returned in the response. The intention here should be a "name", but what "name" means will depends on the implementation.

As such, there is no bit of extra info in the keyring spec which we can generalize to the EDK structure. I'm closing this issue as a no-op.