aws-eks: Helm Chart support for TAR archives

### Describe the feature

When using the L2 construct within the `aws_eks_v2_alpha` library defining a `HelmChart` construct, a `chartAsset` can optionally be specified instead of specifying a repository, but currently, only assets packaged as ZIP archives are supported:

https://github.com/aws/aws-cdk/blob/3d948c4eeb6ffc8e5d3203220fe7799dffbd59ef/packages/%40aws-cdk/aws-eks-v2-alpha/lib/kubectl-handler/helm/__init__.py#L20-L29

This creates an issue (e.g. non AWS-managed EKS drivers) when pulling a chart (on Linux/MacOS) which is then provided as a TGZ, for example:

```
helm pull aws-secrets-manager/secrets-store-csi-driver-provider-aws -d temp/charts
```

I suggest the `kubectl-handler` should support the typical formats returned `helm pull ...` across the main OS types.

### Use Case

When deploying helm charts to an air-gapped EKS cluster, they must be hosted in a way that is accessible to the `kubectl-handler` to pull it.

One way of achieving this is to upload helm charts using the CDK S3 Assets feature, Python example:

```
TEMP_CHARTS = 'temp/charts' # Generated outside of CDK

cluster = ... # An EKS Cluster created using the L2 construct from `aws_eks_v2_alpha`

driver_version = '1.4.8'

stack = Stack.of(construct)
prefix = f'{stack.account}.dkr.ecr.{stack.region}.amazonaws.com'

eks.HelmChart(
self, 'SecretsStoreCsiDriverChart', cluster=cluster, namespace='kube-system',
chart_asset=s3_assets.Asset(
self, 'ChartAsset', path=f'{TEMP_CHARTS}/secrets-store-csi-driver-${driver_version}.zip'
),
values={
'linux': {
'image': {
'repository': f'{prefix}/kubernetes/csi-secrets-store/driver'
},
'crds': {
'image': {
'repository': f'{prefix}/kubernetes/csi-secrets-store/driver-crds'
}
}
}
}
)
```

In the above, the default references to public repositories have been replaced with references to private ECR repos into which the required driver container image has been pushed.

The problem arises because the path to the asset (`f'{TEMP_CHARTS}/secrets-store-csi-driver-${driver_version}.zip'`) currently references a `.zip` file, when in practice the output for this chart from a `helm pull ...` command is a `.tgz`.

### Proposed Solution

Support multiple archive formats (at least ZIP and TAR GZ) within the `kubectl-handler/helm` module. Python has the builtin package `tarfile` which should suffice.

### Workaround
Extract the non-ZIP'd helm chart package and repackage it as a ZIP, achieved using the following example shell snippet:

```
repo_name='aws-secrets-manager'
chart_name='secrets-store-csi-driver-provider-aws'

temp_dir='temp/charts'
mkdir -p "$temp_dir"
helm pull "${repo_name}/${chart_name}" -d "$temp_dir" --untar
version=$(helm show chart "temp/charts/${chart_name}" | awk '/version/ {print $2}')

(export temp_dir chart_name version && cur=$(pwd) && cd "${temp_dir}/${chart_name}" && zip -r "${cur}/${temp_dir}/${chart_name}-${version}.zip" .)
```

### Other Information

On the face of it, pushing a copy of the chart into ECR should also work, but I struggled to get the `kubectl-handler` to successfully pull from it, hence resorted to referencing the chart as an S3 assets.

### Acknowledgements

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

### CDK version used

2.1002.0 (build 09ef5a0)

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

MacOS

Start in packages/@aws-cdk/aws-eks-v2-alpha/lib/kubectl-handler/helm/__init__.py, particularly the asset archive handling linked in the issue. Trace how HelmChart chartAsset files are recognized and extracted, then verify that ZIP and TAR GZ assets are both handled for the described air-gapped EKS use case.

Written by the indexing model from the issue text.