Helm provider for bicep

In order to round out the kubernetes experience with bicep, it seems clear that we will need a helm provider.

**DISCLAIMER:** I don't use helm or kubernetes day-to-day, so there are probably some statements below that don't make sense! I'm using this issue to get thoughts down on paper and support future discussions.

## Scenarios

Helm serves three distinct use cases today:

**I need dynamic kubernetes manifests, which helm allows me to do via chart templates (YAML files in the `templates/` directory)**
* Helm seems like overkill if this is the only need. There are seemingly lots and lots of options for [templating manifests](https://github.com/kubernetes/kubernetes/issues/23896#issuecomment-313544857).
* With the kubernetes provider for bicep, we are introducing yet another way of templating out a manifest. If we built a helm provider, it would not be to address this scenario.

**I need to install helm charts**
* Without a helm provider, this won't be possible with bicep, other than with a deployment script. We actually have a dedicated [`aks-run-helm` module](https://github.com/Azure/bicep-registry-modules/tree/main/modules/deployment-scripts/aks-run-helm#running-a-simple-command) in the public registry for this purpose.
* While it's possible some users may want to convert their helm chart to bicep, there are many reasons why you would still want to author a helm chart.
- I need my helm chart to be installable in bicep and non-bicep scenarios.
- If I am not the owner/maintainer of the chart, then I have no way of getting the helm chart converted (nor may I want to)
* This potentially could help with migration from helm chart to bicep k8s provider (if needed)

**Declarative deletion**
* helm has stacks-like behavior. Need to fill in details...

Some pseudo-code for a helm provider might look like the following (based on [how this is implemented in TF](https://registry.terraform.io/providers/hashicorp/helm/latest/docs)):

```bicep
resource chartInstall 'helm/release@v1' = {
repository: 'https://charts.bitnami.com/bitnami' // I would assume we can support "local" charts in addition to ones in a registry?
chart: 'nginx-ingress-controller'

// could support keys/values or loadYamlContent() assuming there is already a `values.yaml` file
values: {
foo: 'bar'
}
// values: loadYamlContent('values.yaml')
}
```

* tf uses `set` because helm CLI uses `set`
* need to support `set_sensitive` for secrets

## Implementation

One of the barriers to implementation is the lack of a .NET client for Helm. The canonical way to build helm "apps" would be to use the Go SDK.

Some implementation options that have not been given much thought:
* Build first-class support creating providers in Go
* Support container-based providers using a defined RPC. We built a prototype of this for our most recent hackathon.
* this is more desirable than Option 1
* Call the helm CLI via a .NET bicep provider. This is the hackiest option, but also the lowest cost.
* helm CLI supports a JSON output, so there would be some element of maintainability/supportability
* helm CLI would need support for multi-tenancy, isolation, etc.

## Open questions

* Do we actually need this? How many use cases exist for Bicep + k8s if we don't support helm?
* Do we need this so urgently that we should implement via the hacky solution?
* How do we support local charts? Need to somehow package the chart using loadFileAsBase64 or something like that..
- this is a very important scenario for anyone authoring their own helm charts
* Need to provide an async experience, which bicep providers do not support yet today.

No files, tests, or implementation entry points are identified. Start by reviewing the Scenarios, Implementation, and Open questions sections, then investigate the proposed Helm provider approaches and their async, local-chart, and isolation requirements. Done would require an agreed scope and implementation path rather than the exploratory discussion currently described.

Written by the indexing model from the issue text.