AWS::KMS::KeyPolicy is desired

`AWS::KMS::Key` supports configuring a resource policy as a property on the object, but not as its own resource. Given that by default, keys must have a statement both in the key resource policy as well as on the IAM identity policy to allow an operation such as `iam:Encrypt`, this makes it impossible to create a `Key` with restrictive permissions in Stack 1, and a `Role` in Stack 2 that can use that key.

This is because at the time of `Key` creation (Stack 1), when we're setting the key policy, we won't know the name of the `Role` yet that will be created in Stack 2, so we can't properly reference it.

What we would like to be able to write is this:

```
==== STACK 1 ============
Resources:
MyKey:
Type: AWS::KMS::Key
Properties:
Policy: ... # <-- can't refer to MyRole here!
Outputs:
KeyArn:
Value: { Fn::GetAtt: [MyKey, Arn] }
Export: SharedKeyArn

==== STACK 2 ============
Resources:
MyRole:
Type: AWS::IAM::Role
Properties: # ...
RolePolicy:
Type: AWS::IAM::Policy
Properties:
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action: 'kms:Decrypt'
Resource: { Fn::ImportValue: SharedKeyArn }
Roles:
- {Ref: MyRole}
ChangeKeyPolicy: # <-- MUST encode this operation in Stack 2
Type: AWS::KMS::KeyPolicy
Properties:
KeyArn: { Fn::ImportValue: SharedKeyArn }
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action: 'kms:Decrypt'
Principal: { Fn::GetAtt: [MyRole, Arn] }
```

Compare: `AWS::S3::BucketPolicy`, `AWS::SQS::QueuePolicy`, etc, which encapsulate the operation of adding to a resource's policy, so that this operation can be done in a cross-stack fashion.

## 5. Helpful links

A grant must be present in both the key policy and the identity's IAM policy. Source:

https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html#managing-access

> IAM policies by themselves are not sufficient to allow access to a CMK.

## 6. Category (required) - Will help with tagging and be easier to find by other users to +1

8. Security (IAM, KMS...)