Feature Request: Remove values.yaml in Aspire Kubernetes Publish and Inline Configuration in ConfigMaps and Services.

Summary
Aspire’s Kubernetes publish currently relies on a centralized values.yaml to inject parameters into Helm templates:

```
spec:
containers:
- image: "{{ .Values.parameters.datanex.datanex_image }}"
```

This request proposes eliminating values.yaml and moving all runtime settings—images, ports, env vars, volume mounts—directly into Kubernetes-native manifests (ConfigMaps, Secrets, Service, Deployment) for clearer, self-contained configuration.

Motivation
- Simplify chart maintenance by removing the indirection layer between values.yaml and templates.
- Make manifests consumable by both Helm and non-Helm users without extra boilerplate.
- Improve discoverability: operators can inspect a ConfigMap or Service and immediately see live configuration.
- Enforce a declarative, Kubernetes-first mindset across all Aspire modules.

Proposal
- Drop the values.yaml file from all Aspire charts.
- Embed configuration in Kubernetes resources:
- Use a single ConfigMap (and Secrets) for image names, ports, environment variables, resource limits.
- Reference those directly in Deployment, Service, and other manifests.
- Update documentation and examples to reflect the new pattern.

Alternatives Considered
- Keep values.yaml but generate a ConfigMap hook post-install.
- Offer an opt-in toggle (useValuesFile: true|false) to support both modes.

Impacts & Migration
- Breaking change for existing users relying on values.yaml.
- Provide a migration guide to translate values.yaml entries into the new ConfigMap-driven model.
- Update CI pipelines, tests, and documentation accordingly.

Acceptance Criteria
- [ ] Remove values.yaml from all Aspire chart repos.
- [ ] All templates exclusively reference ConfigMaps, Secrets, or inline fields.
- [ ] CI and Helm lint/tests pass with the new manifests.
- [ ] Documentation and migration guide published.

Start by inventorying values.yaml files across the Aspire chart repositories and tracing their references through the Helm templates. Review the related CI, Helm lint/tests, documentation, and examples before deciding how ConfigMaps, Secrets, and inline fields replace the current inputs. Done means the charts no longer depend on values.yaml, checks pass, and migration documentation is published.

Written by the indexing model from the issue text.