Add per-component image overrides to Helm chart

[biankabekefi-cldr]

Add optional per-component image overrides under images.airflow in the Helm chart.

Operators can now set a different repository, tag, or digest for the main container of:

• API server (images.airflow.apiServer)
• Scheduler (images.airflow.scheduler)
• DAG processor (images.airflow.dagProcessor)
• Triggerer (images.airflow.triggerer)

Omitted fields inherit from the global images.airflow settings, then from defaultAirflowRepository, defaultAirflowTag, and defaultAirflowDigest. When both tag and digest are set for a component, digest takes precedence (same behavior as the existing airflow_image helper).

Empty component blocks ({}) are the default in [chart/values.yaml](chart/values.yaml), so existing deployments are unchanged unless overrides are explicitly set.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[Miretpl]

In some sense similar to #63514. I prefer the direction in which #63514 is going - move to a per-component image section instead of a global one. This is also in line with Helm Chart direction reflected in #64037. Moving to per-component is more flexible and provides groundwork for feature support, e.g., multi-team features.