Add "atmos helmfile template" command

### Describe the Feature

Enhance `atmos helmfile` with an additional `atmos helmfile template` subcommand which runs `helmfile template` for the specified component and stack, with the generated `values.yaml` file.

### Expected Behavior

```shell
$ atmos helmfile template -s
# Generating components/helmfile//-.helmfile.vars.yaml
# Source: /templates/networkpolicy.yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name:
namespace: "default"
...
```

### Use Case

This would allow a workflow where helm components are described and managed consistently with terraform components by product teams in a "product deployment repository", and handled by a CI to generate the K8S manifests and push them to an ArgoCD monitored git repo.

This also enables the CI to mimic the tf plan behavior and diff the generated manifests with those in the ArgoCD repo. I know `atmos helmfile diff` does this, but it can only do it against an existing cluster with appropriate credentials, which rules out clusters running with in-cluster ArgoCD, where no cluster credentials is accessible otherwise.

A nice companion to the feature would be a `--reference` argument added to `atmos helmfile diff`:

```shell
$ atmos helmfile diff -s --reference git://github.com/myorg/argocd//.yaml
```

### Describe Ideal Solution

MVP: Exactly what I described in the feature description.
Final product: this is taken care of by Atmos Pro similarly to Terraform components, with some sort of hooks to receive and handle the generated manifests (in my case, to push them to the appropriate git repo and path).

### Alternatives Considered

I kind of hacked the behavior myself with an atmos custom command:

atmos.yaml:

```yaml
commands:
- name: helm-template
description: Generate K8S manifests for the given helmfile component and stack, so they can be pushed to an ArgoCD monitored repo
arguments:
- name: component
description: Helmfile component
required: true
flags:
- name: stack
shorthand: s
description: Atmos stack to deploy the component for
required: true
env:
- key: ATMOS_COMPONENT_NAME
value: "{{ .Arguments.component }}"
- key: ATMOS_STACK_NAME
value: "{{ .Flags.stack }}"
- key: GENERATED_HELM_VALUES_FILE # Used to compute the values file in helmfile config
value: "{{ .Flags.stack }}-{{ .Arguments.component }}.helmfile.vars.yaml"
steps:
- atmos helmfile generate varfile $ATMOS_COMPONENT_NAME -s $ATMOS_STACK_NAME
- |
ATMOS_COMPONENT=$(atmos describe component $ATMOS_COMPONENT_NAME -s $ATMOS_STACK_NAME --query '.component')
helmfile template -f atmos_test/components/helmfile/$ATMOS_COMPONENT/helmfile.yaml
```

components/helmfile//helmfile.yaml
```yaml
repositories:
- name: bitnami
url: https://charts.bitnami.com/bitnami

releases:
- name: whatever
namespace: default
chart: bitnami/whatever
values:
- ./{{ env "GENERATED_HELM_VALUES_FILE" }}
```

### Additional Context

_No response_

Start with the existing `atmos helmfile` command and its `generate varfile` entry point. Trace how the component and stack select `components/helmfile//helmfile.yaml` and generate the values file, then verify that the new command runs `helmfile template` and emits the rendered manifests for the requested component and stack.

Written by the indexing model from the issue text.