[eks] [request]: Kubernetes operator to manage add-ons

### 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**
I'd like the EKS add-ons to be implemented as an open source Kubernetes operator, optionally installed into the cluster control plane, with CRDs to allow add-on customisation. This operator should contain the full EKS add-on operational logic in a single place and be available to use in all EKS clusters.

Initially this operator could be manually installed into a [bare EKS cluster](https://github.com/aws/containers-roadmap/issues/923) and used to manage add-ons. Ideally this operator would be optionally installed and used for the current "install only" and "basic managed" lifecycles while also being able to support full customisation lifecycles via CRD manipulation. The operator could still look the same in the EKS dashboard and interact with the CLI, so could be just an implementation detail in some modes. This operator would also be able to be enabled/disabled at will (via a CRD `enabled` field), which would allow self-management on top of the managed config and re-alignment at a point in the future. By making this operator optional, it could be released in parallel to the existing add-ons implementation and it could be manually managed by cluster operators where this made more sense for them.

This operator has additional benefits such as working in an air gapped environment, by containing the required logic and providing custom repository information via the CRDs.

This could also support the running of certain add-ons, like Karpenter, on the control plane which would be a game changer in managed K8s.

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

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
The current add-on model isn't Kubernetes native, isn't very configurable or observable and (I assume) needs the cluster to be connected. I'd like to be able to create a bare EKS cluster and configure the add-ons with precise details.

**Are you currently working around this issue?**
We uninstall all add-ons when we create a cluster and re-add them to our own specification.

**Additional context**
I'd be happy to contribute to such a project as this is something I might need to build anyway.

**Attachments**
n/a

Start by reading the EKS add-ons request and the referenced bare EKS cluster issue #923, then examine how EKS add-ons are currently exposed through the dashboard and CLI. The requested outcome is a Kubernetes operator with CRDs for add-on customization, optional installation, and support for managed and fully customized lifecycles; no repository files or tests are named.

Written by the indexing model from the issue text.