Option for CloudFormation stack to "pause" further resource deletions when first DELETE_FAILED is encountered.

### Name of the resource

Other

### Resource name

CloudFormation Delete Workflow

### Description

Hello team,

Please consider this as a Feature Request.

Scope of the Feature request: We currently see that when we initiate a delete on CloudFormation stack, if one ore more resources encounter failures during their deletions (due to IAM permission issues, resource specific issues, dependency issues, etc.), the CloudFormation stack goes ahead and continues to delete the rest of the resources.

However, this can be set as the default behaviour and users can be given an option to sort of "pause" the deletion of the stack and not make further deletions. When the user comes back, they have the option to re-retry the delete that failed after fixing the error root cause and then proceed with further resource deletions.

### Other Details

Additional context:
An example where this can be useful is that for users who are making use of "DependsOn" attribute between two resources, lets say resource A -> DependsOn -> resource B. Now since resource A gets deleted first due to an error, if it fails and resource B succeeds in its deletion, users can find themselves in a situation where the deletion of resource A is not going through now because it expects resource B to be active (basically a different error now).

Example:
- Create a CloudFormation stack with ```AWS::RDS::DBCluster``` and ```AWS::SecretsManager::Secret``` resources.
- Upon deletion of the stack now, lets say the stack fails with an error like **```Cluster cannot be deleted, it still contains DB instances in non-deleting state```** (which is a fairly common when using RDS resources).
- Now, since the secret being referenced is also being managed by CloudFormation stack, it got deleted successfully though RDS cluster failed.
- Now user makes sure that all DB Instances are in "deletable" state and retries the stack deletion but faces the error: **```Secrets Manager can't find the specified secret```**.
- However this secret was not deleted by the user by CloudFormation itself.
- Had there been an option to "pause" the delete upon first failure, user would have enabled it -> fix the RDS DB Instances -> retry the stack deletion which would go through successfully. (something similar to "disabling rollback" and "retry" but in DELETE here).
- Sure, users have the option to retain the DELETE_FAILED resources but there are many who are more CICD inclined and do not wish to perform manual actions.

Similar examples can be drawn between quite a few dependent resources. This option can surely be helpful to users who really know what they’re doing when they enable this option.

No repository file, test, or implementation entry point is identified. Start by reviewing the deletion and dependency examples in the issue, then clarify the control's semantics, retry behavior, and interaction with retained resources; done means a user-selectable pause prevents further deletions after the first DELETE_FAILED and allows the failed deletion to be retried.

Written by the indexing model from the issue text.