**NOTE:** This PR bumps the version of the bootstrap stack to `16`, but
there is no need to update your bootstrap stacks, unless it is to get
rid of the Security Hub finding; this change has no effect on the
functionality of any CDK app deployed to the environment.

[Security Hub finding
KMS.2](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html#kms-2)
says:

> The control fails if the policy is open enough to allow kms:Decrypt or kms:ReEncryptFrom actions on any arbitrary KMS key.
>
> [...]
>
> The control only checks KMS keys in the Resource element and doesn't take into account any conditionals in the Condition element of a policy.

While are confident that this control is overly sensitive, and there is
no actual security impact from the current configuration of the policy,
customers are anxious about the Security Hub findings reported on
resources we create.

Therefore, we turn the `Resources: *` into a list of wildcard ARNs, one
for each trusted account. This should satisify Security Hub without
breaking the functionality of the bootstrap resources (as this statement
is only used for cross-account CodePipeline deployments using CDK
Pipelines).

The CloudFormation expression we use to turn a list of account IDs
into a list of ARNs is quite crazy. I would have used `${AWS::Region}`
instead of allowing all regions, but `{ Fn::Join }` doesn't allow
using intrinsics in its separator.

I tested the new template using a CDK Pipeline that deploys in-region,
cross-region, cross-account and cross-account-cross-region.