ExecutionRoles optional global resource attribute

## 1. Title
ExecutionRoles optional global resource attribute

## 2. Scope of request
CloudFormation currently optionally supports `CreationPolicy`, `DeletionPolicy` among others [resource attributes](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-product-attribute-reference.html) globally for all resources.

This proposal would introduce a new `ExecutionRoles` optional resource attribute, which specifies one or a list of IAM role ARNs CloudFormation would assume in order to perform CRUD operation on the resource. For convenience, I'm also including in the scope of this request the introduction of a new [pseudo parameter](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html), `AWS::ExecutionRoleArn`, that would resolve to the ARN of the role CloudFormation is currently using to the deploy the stack.

It may also be useful to introduce a [top-level key](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html) with the same name, in order to avoid code repetition. But this is beyond the initial scope of this request.

## 3. Expected behavior

If omitted, the attribute should evaluate to `!Ref AWS::ExecutionRole`, in order words, the resource would be deployed and managed in the current account and region. This would in no way break backwards compatibility with the way templates are evaluated currently.

If specified, the CloudFormation would use its current execution role to perform a `sts:AssumeRole` operation to the specified role and deploy and manage that specific resource (or the entire stack in the case of the top-level key) using the specified role ARN(s).

Also, when a list of roles is specified, the resource's return values would be a list, with the return values **in the order of the roles as specified in the resource attribute**. This values could then be referenced with the [Fn::Select](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-select.html) intrinsic function.

## 4. Suggest specific test cases

Assuming 3 AWS accounts, each belonging to a different organization, with the following roles:

### `arn:aws:iam::111111111111:role/CloudFormation`

**Trust policy**

```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```

**Permissions policy**
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resources": ["arn:aws:iam::222222222222:role/BucketDeployer", "arn:aws:iam::333333333333:role/BucketDeployer"]
}
]
}
```

### `arn:aws:iam::222222222222:role/BucketDeployer` and `arn:aws:iam::333333333333:role/BucketDeployer`

**Trust policy**

```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/CloudFormation"
},
"Action": "sts:AssumeRole"
}
]
}
```

**Permissions policy**
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
```

Now suppose that the account `111111111111` deploys the following CloudFormation stack:

```yaml
AWSTemplateFormatVersion: 2010-09-09

Resources:
Bucket:
Type: AWS::S3::Bucket
ExecutionRoles:
- !Ref AWS::ExecutionRole
- arn:aws:iam::222222222222:role/BucketDeployer
- arn:aws:iam::333333333333:role/BucketDeployer

Outputs:
CurrentAccountBucketName:
Description: Bucket deployed to this account (111111111111)
Value: !Select [0, !Ref Bucket]

2AccountBucketName:
Description: Bucket deployed to account 222222222222
Value: !Select [1, !Ref Bucket]

3AccountBucketName:
Description: Bucket deployed to account 333333333333
Value: !Select [2, !Ref Bucket]
```

**Important**
It's also worth noting that I'm not proposing here that secondary stacks should be created in accounts `222222222222` and `333333333333`. From the perspective of these accounts the buckets created are not part of a CloudFormation stack, they behave as regular resources.

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

N/A

## 6. Category

11. Other

## 7. Any additional context (optional)

This would be a significant improvement over the current approach using `AWS::CloudFormation::StackSets`, especially for teams that manage stacks across multiple AWS Organizations. In particular, this would allow for referecing resources deployed to other accounts within the same template.

No repository files, tests, or implementation entry points are mentioned. Start by reviewing the linked CloudFormation resource-attribute and pseudo-parameter references, then compare the proposal with StackSets. Done would require agreed behavior for single and multiple role ARNs, returned values, the pseudo parameter, permissions, and backward compatibility.

Written by the indexing model from the issue text.