Rewrite EKS L2 construct (EKSv2)

## Description
When an EKS cluster is created, the only role that has access to the cluster itself (e.g running kubectl commands) is the role that created the cluster. When using CloudFormation, this would be the CloudFormation execution role. Since this role isn’t assumable by anyone, it effectively means it is impossible to connect to the cluster post creation.
In CDK, we workaround this issue by implementing the L2 using **custom resources**, instead of L1s. This allows us to **create** the role that creates the cluster (i.e invokes `eks.CreateCluster` API), and subsequently use this role to grant additional (user defined) roles permissions on the cluster.
The EKS team added a [new feature](https://aws.amazon.com/blogs/containers/a-deep-dive-into-simplified-amazon-eks-access-management-controls/) that allows more control over cluster access. Now it would be possible for CloudFormation to specify a list of roles to be granted access to the cluster, in addition to the role that creates the cluster.
The RFC is to create a new EKS L2 construct and drop the custom resource implementation in favor of the native L1.

This is going to incur a breaking change that will require cluster replacement (because type will change from Custom::AWSCDK-EKS-Cluster to AWS::EKS::Cluster). Given a breaking change is inevitable, we can decide also to make some additional breaking changes in the API that make it more ergonomic and aligned with the new cluster implementation.

## Roles

| Role | User
|---------------------|------------------------------
| Proposed by | @evgenyka
| Author(s) | @xazhao
| API Bar Raiser | @iliapolo
| Stakeholders | @alias, @alias, @alias

> See [RFC Process](https://github.com/aws/aws-cdk-rfcs#rfc-process) for details

## Workflow

- [x] Tracking issue created (label: `status/proposed`)
- [x] API bar raiser assigned (ping us at [#aws-cdk-rfcs](https://cdk-dev.slack.com/archives/C025ZFGMUCD) if needed)
- [x] Kick off meeting
- [x] RFC pull request submitted (label: `status/review`)
- [x] Community reach out (via Slack and/or Twitter)
- [x] API signed-off (label `status/api-approved` applied to pull request)
- [x] Final comments period (label: `status/final-comments-period`)
- [x] Approved and merged (label: `status/approved`)
- [x] Execution plan submitted (label: `status/planning`)
- [x] Plan approved and merged (label: `status/implementing`)
- [x] Implementation complete (label: `status/done`)

---

> Author is responsible to progress the RFC according to this checklist, and
apply the relevant labels to this issue so that the RFC table in README gets
updated.

Start with the RFC description and the linked RFC Process, then verify the status of the approved execution plan and implementation referenced by the completed workflow. Done means a new EKS L2 construct uses the native AWS::EKS::Cluster resource instead of the custom resource and supports granting user-defined roles cluster access.

Written by the indexing model from the issue text.