Add --helm-dependency-update flag to run helm dependency update when --enable-helm is set

### Eschewed features - [x] This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature. ### What would you like to have added? The feature flag --enable-helm works great for publicly accessible repositories but fails if a local chart is used which itself has other HELM dependencies like so: ```yaml apiVersion: v2 name: my-custom-chart description: Custom chart to deploy Harbor and custom manifests type: application version: 0.1.0 dependencies: - name: harbor version: "1.18.3" repository: "https://helm.goharbor.io" ``` If you run `helm dependency update` or `helm repo add` + `helm dependency build` wherever the chart itself lives, everything works fine again. This is to be expected, since now `kustomize` is happy since it can easily resolve all dependencies again and can render the chart. However, `helm dependency update` is a quite expensive operations and runs outside of `kustomize` itself (since it depends fully on `HELM` itself like `--enable-helm` already does). Therefore, this feature must be opt-in only. ### Why is this needed? The reason is simple - `ArgoCD`. If you use `kustomize` + `HELM` for a single `ArgoCD` project you will run into issues if your `HELM` chart has any dependencies. Using `kustomize` + `HELM` for single projects is desired in some cases since this allows for patching of otherwise inaccessible resources created by the chart, allows for better handling with sealed-secrets and might just be the intended way by some CI/CD teams to better keep track of rendered manifests. Ultimately, `ArgoCD` just runs `kustomize build --enable-helm` if it sees a `kustomize.yaml` file. You could make a cases that this feature may be implemented into the ArgoCD project instead. However, by adding this feature into `kustomize` instead, it allows for other project which might use `kustomize` but not `ArgoCD` to also benefit from this. ### Can you accomplish the motivating task without this feature, and if so, how? Yes, but it is quite cumbersome. Here are some ideas on how this might be resolved: - Fork the `kustomize` repository, implement the feature yourself, create a custom `ArgoCD` Docker image which uses the custom `kustomize` binary instead and use that for your projects - Create a custom config map in `ArgoCD` which allows for "`kustomized-helm`" runs by providing a custom Docker image which has `kustomize` and `HELM` preinstalled which first runs `helm dependency update` and then runs `kustomize build --enable-helm` - Simply commit the `chart` folder containing the dependent charts into your repository (but this is not really best-practice) ### What other solutions have you considered? You could make the case for either using `kustomize` or `HELM` but not mixing them. However, for our specific use-case, we need both in conjunction. There simply isn't an alternative which does not introduce more management overhead. ### Anything else we should know? I have built a local PoC of this by adding the optional flag `--helm-dependency-update` which works if the flag `--enable-helm` is also present. If both flags are set, `kustomize` will simply run `helm dependency update` within all folders where a `Chart.yaml` is present. It works fine and does not introduce any breaking changes. Therefore, this won't impact any existing workflows / use cases. ### Feature ownership - [x] I am interested in contributing this feature myself! 🎉