(aws-eks): Support `--take-ownership` flag in new helm version

### Describe the feature

The newest helm release (scheduled to come out tomorrow Jan 15, 2025), has a `--take-ownership` flag provided for the upgrade and install commands. We would want to open up this flag as a parameter for the HelmChart Custom Resource so that (provided there is the correct helm version in the KubectlLayer), IAC can specify something like:

```typescript
new eks.HelmChart(this, 'my-chart', {
...previousProps,
// We are okay with taking over resources that we may have already applied in manual migrations
takeOwnership: true,
};
```

### Use Case

A general use case is that a Devops team is testing particular configurations for some version upgrade of a helm chart or for turning on some previously unturned on feature. In this case, the team might manually deploy some manifests so that they can vary different values and then soak test afterwards. The devops team would expect that they could add these features to the helm chart construct after the fact and have helm take over the zero-sum change by applying its upgrade.

The last assumption right now does not work though because helm will not succeed if ownership annotations are missing and will break your IAC deploy pipeline despite you thinking you were just bringing things up to parity. The new `--take-ownership` [feature](https://github.com/helm/helm/pull/13439) solves this problem and will allow DevOps personnel to make the conscious choice to run the flag and avoid deployment triage that either involves finding all discrepancies and patching helm-specific ownership or deleting resources to have them recreated (potentially creating some downtime).

A direct use case for me is that [ArgoCD does not have the ability to add annotations for a helm chart ](https://github.com/argoproj/argo-cd/issues/21250#issuecomment-2588059119)(this traces back to how the helm library implements its template API). Because of this, experimentation through the better visibility tool of ArgoCD for a helm chart that CDK deploys ends up blocking the next cluster deployment that tries to also create the new manifest that was previously tested.

### Proposed Solution

1. Add a `takeOwnership?: boolean` option to the eks.HelmChart Construct
2. Update the KubectlHandler code to apply the take-ownership option
3. Since this is version specific, it would be ideal to verify the helm version during synth and throw an error if the option wouldn't be supported - I believe this could be achieved by updating the KubectlLayer libraries with a "helmVersion" field and retrieving that?
4. If the synth time option isn't possible, then at least providing a descriptive thrown error from the custom resource handler

An obvious requirement here is that this needs to be an opt-in flag, so that default behavior of all other existing HelmCharts are preserved.

I think that would be about it, unless I'm missing something.

### Other Information

_No response_

### Acknowledgements

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

### CDK version used

2.175.1

### Environment details (OS name and version, etc.)

Any environment

Start with the eks.HelmChart construct and the KubectlHandler entry point, then inspect how the KubectlLayer supplies its Helm version. Verify how an opt-in takeOwnership setting can reach Helm install and upgrade operations, and define the expected error behavior when the Helm version lacks support.

Written by the indexing model from the issue text.