AWS::Elasticsearch::Domain - CognitoOptions-RoleMapping: Allow Cognito group role resolution out of the box

## 2. Scope of request

The [`CognitoOptions`](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticsearch-domain-cognitooptions.html) attribute works well to get Elasticsearch up and running with an existing user + identity pool. However, in practice, it feels a little too like a black box.

This request is to add some kind of additional option so that a role mapping of `Token` can be applied easily. We use roles attached to Cognito groups to identify users for Kibana tenants.

As a workaround we've had to do something like this so that the group role is utilised. By default the mappings will use the default roles of the identity pool... which may be blank:
```yaml
IdentityPoolAuthRoleAttachment:
Type: AWS::Cognito::IdentityPoolRoleAttachment
Properties:
IdentityPoolId: {'Fn::ImportValue': !Sub '${ParentVPCStack}-Cognito-IdentityPoolId'}
RoleMappings:
eu-west-2-the-user-pool-ID-I-Know:an-app-client-ID-I-dont:
Type: Token
AmbiguousRoleResolution: Deny
Roles:
```

Here is where the 'black box' feeling comes in. The Elasticsearch service is the one that mutates the user pool by creating an app client and then updates the identity pool. Now logicially I would then consider the Elasticsearch service to be the owner of the app client, but there's no way (in CloudFormation) to get the generated client ID from the Domain resource, *nor* are there convenient knobs to configure any settings when it changes these existing resources.

The workaround has been to use a custom resource to extract some details from a `DescribeIdentityPool` request, but the output of this seems a little hacky. Should there be more than one Cognito user pool in the identity provider it's difficult to work out which was created by ES. Being able to fetch this client ID would be useful, but really this option would be more helpful.

## 3. Expected behavior

An additional option which will set "Token" when creating (or updating, though I've not tried that behaviour at all yet!):
```yaml
ElasticSearchDomain:
Type: AWS::Elasticsearch::Domain
Properties:
CognitoOptions:
Enabled: true
IdentityPoolId: my-identity-pool-subject-to-mutation
RoleArn: some-role
UserPoolId: my-user-pool
# New:
RoleMapping: Token # If the Cognito user has a group role, use that.
```

## 5. Helpful Links to speed up research and evaluation

May be a continuation of #55?

## 6. Category

7. Analytics (Athena, EMR, Glue,...)

Start with the linked CloudFormation CognitoOptions documentation and the AWS::Cognito::IdentityPoolRoleAttachment example in the issue. Compare the requested RoleMapping behavior with DescribeIdentityPool results and the existing custom-resource workaround, including updates as well as creation. Done means CloudFormation exposes a supported option that applies Token role mapping for the Elasticsearch domain.

Written by the indexing model from the issue text.