feat(continuous-delivery): assets in environment-agnostic stacks (#93)

Originally, we planned to disallow the use of assets by environment-agnostic stacks (e.g. stacks that are defined with pseudo ACCOUNT/REGION in `env`). The problem is that today this is the default behavior for `new Stack()`, which obviously can't work. The original plan was to modify the default behavior of `env` (see aws/aws-cdk#4131), and we still want to pursue this, but since this change in default behavior has potential risk involved, we wanted to decouple it from our CI/CD delivery.

Therefore, this change updates the CI/CD and cdk-assets RFCs to support assets in environment-agnostic stacks by allowing the use `${AWS::Region}` and `${AWS::AccountId}` in `assets.json`.

text/0049-continuous-delivery.md

@@ -196,7 +196,9 @@ The proposal described in [PR#4131](https://github.com/aws/aws-cdk/pull/4131) su
 
 This means that the only way to produce environment-agnostic templates will be to explicitly indicate it when a stack is defined.
 
-Since the specific account and region are required when resolving asset consumption and publishing locations, the current plan is for the default asset store implementation to **fail if assets are used from environment-agnostic stacks**. Again, bear in mind that the current behavior (where the default is environment-agnostic stacks) is going to be changed.
+Then `cdk-assets` will simply substitute `${AWS::ACCOUNT}` and `${AWS::REGION}` with the account and region derived from the credentials configured for the CLI.
+
+> NOTE: even when an IAM role from another account is assumed for publishing, `${AWS::ACCOUNT}` and `${AWS::REGION}` always resolve to the CLI configuration and not to the other account.
 
 ## Bootstrapping
 

text/0092-asset-publishing.md

@@ -24,7 +24,10 @@ The main components of the assets manifest are:
 
 * **Destinations:** describe where the asset should be published. At a minimum, for file assets, it includes the S3 bucket and object key and for docker images it includes the repository and image names. A destination may also indicate that an IAM role must be assumed in order to support cross environment publishing. 
 
-  > Destinations are intentionally denormalized in order to keep the logic of where assets are published at the application or framework level and not in this tool. For example, consider a deployment system which requires that all assets are always published to the same location, and then replicated through some other means to their actual consumption point. Alternatively, a user may have unique security requirements that will require certain assets to be stored in dedicated locations (e.g. with a specific key) and others in a different location, even if they all go to the same environment. Therefore, this tool should not take any assumptions on where assets should be published besides the exact instructions in this file.
+NOTES:
+
+* **Denormalization:** destinations are intentionally denormalized in order to keep the logic of where assets are published at the application or framework level and not in this tool. For example, consider a deployment system which requires that all assets are always published to the same location, and then replicated through some other means to their actual consumption point. Alternatively, a user may have unique security requirements that will require certain assets to be stored in dedicated locations (e.g. with a specific key) and others in a different location, even if they all go to the same environment. Therefore, this tool should not take any assumptions on where assets should be published besides the exact instructions in this file.
+* **Environment-agnostic:** In order to allow assets to be used in environment-agnostic stacks, `assets.json` will support two simple substitutions `${AWS::AccountId}` and `${AWS::Region}` which will be replaced with the currently configured account/region (alternatively, we can also decide to support CloudFormation intrinsic functions and pseudo references). The "current" account and region will always refer to the one derived from the CLI configuration even if `assets.json` instructs to assume a role from a different account.
 
 Here is the complete manifest file schema in typescript: