eks: ack prop for potential cluster replacement

### Describe the feature

aws-eks.Cluster has some cluster props that would result in cluster replacement on prop update.

https://github.com/aws/aws-cdk/blob/3928eae1ee92a03ba9959288f05f59d6bd5edcba/packages/%40aws-cdk/custom-resource-handlers/lib/aws-eks/cluster-resource-handler/cluster.ts#L116-L130

And users can hardly tell that from `cdk diff` or `cdk deploy` as the cluster resource is actually a custom resource and we just notice the custom resource props change in this case.

We only notice that the custom resource would change but in fact the existing cluster would be torn down and replaced, resulting data loss.

I think we should have a gatekeeper prop which default value is `false` and only when you explicit set it as `true` will the cluster replacement happen.

### Use Case

as above

### Proposed Solution

I was thinking maybe we can have a [removalPolicy](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.RemovalPolicy.html) prop of the cluster which default to `RETAIN` and the cluster replacement would only happen when the value is `DESTROY`

Another option is to have a `replaceOnUpdate` or `allowReplaceOnUpdate` prop for eks.Cluster which defaults to `false`.

### Other Information

_No response_

### Acknowledgements

- [X] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

### CDK version used

all

### Environment details (OS name and version, etc.)

all

Start with packages/@aws-cdk/custom-resource-handlers/lib/aws-eks/cluster-resource-handler/cluster.ts, especially the referenced lines, and trace how updates to aws-eks.Cluster properties reach the custom resource. Compare the replacement behavior with cdk diff and cdk deploy; done means the chosen acknowledgment or replacement policy prevents unintended cluster replacement while allowing an explicit opt-in.

Written by the indexing model from the issue text.