[EKS] [request]: Requesting managed addon for AWS Gateway API Controller

### 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**
We would like the AWS Gateway API Controller [https://github.com/aws/aws-application-networking-k8s](https://github.com/aws/aws-application-networking-k8s) available as an EKS Addon so we can manage lattice networks from EKS at cluster creation time.

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

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
We would like to be able to install the [AWS Gateway API Controller](https://github.com/aws/aws-application-networking-k8s) via an EKS Addon and push as a value the initial gateway and service CRs for it to reconcile. This would allow us to spin up an EKS cluster with private networking and Endpoint Private Access only but still allow for services on the EKS cluster to be exposed on the lattice network. Effectively this would allow us to avoid having to route network traffic to the Kubernetes API simply to expose a service on the private EKS cluster.

Once this is done we would be able to expose the internal kubernetes service in the default namespace on the lattice network, allowing for communication with the K8s api on the cluster without the need for routable vpc networking:

**Are you currently working around this issue?**
We have to make use of a lambda with permission to talk to the k8s api to install the AWS Gateway API controller and then add the CRs to join the lattice network and expose the service.

**Additional context**
This would solve a highly sought after solution for dealing with private EKS API access (see: [https://github.com/aws/containers-roadmap/issues/1171](https://github.com/aws/containers-roadmap/issues/1171) and would obviate the need for this blueprint which is much more complex than this solution:
- [https://github.com/aws-ia/terraform-aws-eks-blueprints/pull/1687](https://github.com/aws-ia/terraform-aws-eks-blueprints/pull/1687)
- [https://aws.amazon.com/blogs/containers/enable-private-access-to-the-amazon-eks-kubernetes-api-with-aws-privatelink/](https://aws.amazon.com/blogs/containers/enable-private-access-to-the-amazon-eks-kubernetes-api-with-aws-privatelink/)

**Attachments**

No repository file or test is named. Start by reviewing the linked AWS Gateway API Controller repository and the EKS Addon request context; done would mean the controller is available as an EKS Addon and can accept the initial gateway and service custom resources for reconciliation.

Written by the indexing model from the issue text.