Feature Request: Per-resource update ordering (Delete-Before-Create / Create-Before-Delete) [`create_before_destroy` in TF]

### Resource Name

This may be a dumb feature request as it's not how CF was designed and is more a zero-day problem, but this feature request is more to start a discussion. [Terraform supports this OOTB](https://developer.hashicorp.com/terraform/language/meta-arguments#create_before_destroy:~:text=create_before_destroy) and is treated as a first class resource behavior.

Forgive me if this already exists, but I was surprised that I couldn't find an existing ticket / discussion / item on the roadmap.

### Details

**Scope**

Add a first-class, per-resource control to specify update ordering during replacements, e.g.:
- ReplacementStrategy: DeleteBeforeCreate
- ReplacementStrategy: CreateBeforeDelete (current de-facto behavior for many/all resources)

This would complement (not replace) existing attributes like DependsOn, UpdateReplacePolicy, and DeletionPolicy.

**Problem**

When updating a stack, CF often replaces resources by creating the new resource first and deleting the old one later. This default is great for minimizing downtime, but it can't be inverted when you need the old resource to be removed before the new one can be created (for example, when a globally-unique name or account-level quota prevents coexistence) and you don't care about small levels of downtime. Classic examples are IAM role-names, ECS Autoscaling policies, or even expendable stateful resources like S3 buckets (that you don't care are destroyed). See more below.
- DependsOn only controls creation order and does not address deletion-vs-creation ordering on update.
- UpdateReplacePolicy / DeletionPolicy govern what happens to the old resource (retain, snapshot, delete), not when it’s deleted relative to creating the replacement. 

The functionality gap forces brittle workarounds like manual two-phase deploys or custom resources (which are continually being discouraged in CDK).

More common scenarios where this use case is required:
- Resources with globally unique names (e.g., some distribution/domain/etc) where the new item cannot be created while the old one exists.
- Services with strict quotas that disallow two instances of the same resource simultaneously.
- Avoiding cascading churn where partial state is left.

**Proposed Solution**
```yaml
Resources:
MyIAMRole:
Type: AWS::IAM::Role
Properties: { ... }
ReplacementStrategy: DeleteBeforeCreate # or CreateBeforeDelete (default)
```

References:
1. https://stackoverflow.com/questions/52269136/how-to-ensure-resource-deletion-creation-order-during-aws-cloudformation-update
2. https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle
3. https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-attribute-updatereplacepolicy.html
4. https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/resource-type-schema.html#schema-properties-replacementstrategy
5. https://github.com/aws-cloudformation/cloudformation-cli-python-plugin/
6. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html

Start with the CloudFormation update behaviors and resource type schema references linked in the issue, then compare the proposed ReplacementStrategy values with existing DependsOn, UpdateReplacePolicy, and DeletionPolicy behavior. Done means there is an agreed first-class per-resource ordering design that handles replacement updates without breaking those existing controls.

Written by the indexing model from the issue text.