[EKS] [request]: Fully manage node and core services for CDK-deployed EKS clusters

### 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**

When deploying EKS using CDK L3 constructs, CDK will select and deploy a control plane and worker nodes and core services such that you have a working Kubernetes cluster. CloudFormation, and CDK by extension, has a facility to perform a control plane upgrade, but the configuration must be updated manually by the author to include the new layer name for kubectl, node release versions, and any updates to core services. These values and conditions could be easily managed by the deployment system and the responsibility to manage the internal components shouldn't need to be delegated to the user.

When upgrading an existing EKS cluster deployed with CDK, the default configuration should provide the functionality to manage and upgrade all conventional services initially deployed by CDK along with the control plane without user intervention. Options to exclude non-control-plane updates for users who desire to continue to manually manage components should remain available.

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

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

Attempts have been made to solve for this IaC problem through a project called EKS Blueprints. However, EKS Blueprints is very opinionated, and is not appropriate to be used with pre-existing clusters.

A better and more universally usable solution would be to provide this fully managed functionality through CDK/CloudFormation. It is logical to expect that a service that can spawn distributed components in a sane and usable state, that also provides some upgrade functionality, would contain the functionality to properly upgrade all of its distributed functional components at the same time.

**Are you currently working around this issue?**

Completely new clusters at the desired Kubernetes cluster version can be created. To take the pets->cattle analogy to its extreme, this is like culling the whole herd and burning down the farm and starting with a brand new homestead. Any persistent data contained in the cluster will have to be evacuated to the new cluster, and that can be very complicated if maintaining zero-downtime for services is also a requirement.

If upgrades are to be accomplished, upgrades must directly manage the release version numbers for node groups. Core services must be created as "addons" and the compatible version numbers must be provided. As EKS matures, the code an IaC user must write to manage version numbers and addons will continue to grow and become more complex.