[EKS] [request]: Add ability to force rollback EKS add-ons from AWS console

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
Add the ability to force rollback EKS add-ons from the AWS console without the need to interact with the application directly in the cluster.

**Which service(s) is this request for?**
EKS Add-on

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
In a previous incident, a syntax error in the CoreDNS Corefile config caused the CoreDNS add-on to be stuck in the "Updating" status. The new pods were stuck in a crash loop backoff, making it impossible to roll back the change.
We had to manually edit the ConfigMap within the cluster to bring the CoreDNS deployment back up. This manual intervention is not ideal. The lack of a rollback option in the AWS console makes it difficult to recover from such issues quickly and efficiently.

This goes for other EKS Add-ons as well.

**Are you currently working around this issue?**
Currently, the workaround involves manually editing the ConfigMap within the cluster to correct the CoreDNS configuration and bring the deployment back up. This is time-consuming and requires direct interaction with the cluster, which is not always feasible.

**Additional context**
Implementing this feature would improve the resilience and manageability of EKS clusters by allowing administrators to quickly recover from configuration errors without needing to access the cluster directly.

The issue identifies EKS add-ons, the AWS console, and a CoreDNS ConfigMap workaround, but names no repository files, tests, or implementation entry point. Start by understanding the requested console rollback behavior and the failure scenario described; done would require a defined, usable rollback path for affected add-ons without direct cluster interaction.

Written by the indexing model from the issue text.