Add Vertical Pod Autoscaler (VPA) support to EKS CoreDNS add-on configuration

### Community Note
Please vote on this issue by adding a 👍 reaction 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 What do you want us to build?

We request native Vertical Pod Autoscaler (VPA) support integrated into the EKS CoreDNS add-on configuration, allowing users to configure both horizontal and vertical autoscaling within the same add-on without requiring separate VPA objects.

### Which service(s) is this request for?
Amazon EKS - CoreDNS Add-on

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

We're experiencing CoreDNS pods getting OOMKilled during initialization due to memory spikes that exceed default limits (170Mi). During startup, CoreDNS needs to load cluster DNS records, initialize plugins, and establish API connections, causing memory usage to spike to 300Mi+ before stabilizing.

### Current challenges:

1. Manual intervention required: When memory limits are insufficient, pods restart continuously until limits are manually adjusted
2. Resource waste: Setting high static limits wastes resources during steady-state operations
3. Operational complexity: Managing separate VPA objects alongside the EKS add-on creates additional operational overhead
4. Inconsistent scaling: HPA handles replica scaling but memory requirements vary based on cluster size and DNS load

### Impact of not solving this:

1. Service disruptions during cluster scaling events
2. Increased operational burden for platform teams
3. Suboptimal resource utilization across environments
4. Risk of DNS resolution failures during peak initialization periods

### Are you currently working around this issue?

Yes, we're currently implementing workarounds:

1. Static memory limits: Manually setting CoreDNS memory limits to 300Mi+ based on observed usage patterns
2. Separate VPA deployment: Creating standalone VPA objects to manage CoreDNS memory allocation outside the add-on
3. Configuration optimization: Tuning CoreDNS cache settings and plugin configurations to reduce memory footprint
4. Pod anti-affinity rules: Distributing CoreDNS pods across nodes to prevent resource contention

### Current add-on configuration:
```
{
"autoScaling": {
"enabled": true,
"minReplicas": 3,
"maxReplicas": 10
}
}
```

### Desired add-on configuration:

```
{
"autoScaling": {
"enabled": true,
"minReplicas": 3,
"maxReplicas": 10
},
"verticalPodAutoscaler": {
"enabled": true,
"updateMode": "Auto",
"resourcePolicy": {
"minAllowed": {
"memory": "170Mi",
"cpu": "100m"
},
"maxAllowed": {
"memory": "1Gi",
"cpu": "1000m"
}
}
}
}
```

The issue provides no repository files or tests; begin by reviewing the EKS CoreDNS add-on configuration and the requested VPA settings shown in the examples. Done means the add-on natively accepts and applies verticalPodAutoscaler alongside autoScaling, including updateMode and resourcePolicy, without a separate VPA object.

Written by the indexing model from the issue text.