(hotswap): hotswapping should support EKS resources

Please add your 👍 to this issue - that helps us prioritize!

### Description

Add support for hotswapping EKS manifests that are deployed using the `aws-eks` module.

### Use Case

EKS is a method of deploying application code to AWS. Should be supported similar to how ECS and Lambda is supported today.

### Proposed Solution

Currently EKS manifests are deployed using a custom resource provider which uses `kubectl`/`helm` to perform the deployment. We can probably implement a solution similar to how we hotswap s3 deployments. Work was started [here](https://github.com/corymhall/aws-cdk/tree/corymhall/hotswap-eks), but was dependent on adding support for hotswapping in nested stacks (https://github.com/aws/aws-cdk/issues/16508).

### Other information

Some additional notes:

On creation `kubectl` will either perform a `kubectl create` or `kubectl apply` depending on whether `overwrite: true` has been provided to the manifest.
- `create` will fail if the resource already exists
- `apply` will not fail if the resource already exists
Given this, it might be a good idea to always provide `overwrite: true` when hotswapping. It is possible to provide multiple k8s resources in a single manifest, and on a given deployment some can succeed and some can fail.

The `kubectl` deployment will also not wait for the deployment to finish. There are other `kubectl` commands that can be run to monitor the status of the deployment, but these are not currently implemented in the custom resource. If we wanted hotswap to wait for deployments to complete I think we would have to either
1. Update the custom resource to provide this "wait" functionality
2. Make `kubectl` (or EKS API) calls locally with the CDK CLI. This may be limited though since it depends on having network access to the cluster along with eks credentials.

This is further complicated by the fact that multiple types of resources can be deployed in a single manifest and the commands to monitor them may be different.

### Acknowledge

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