Introduce workers.celery and workers.kubernetes config sections

[Miretpl]

closes: #28880

Currently, in the Helm Chart, there is a workers field whose values are shared between Celery and Kubernetes executors workers. The only possible way to configure both separately is by using the podTemplate field, which overrides the whole pod-template-file content. However, there is no easy possibility to override part of the configuration or to share the same configuration between workers.

This PR introduces the workers.celery and workers.kubernetes files, which contain specific fields used by each executor worker. Every field specified under the above sections overrides the value of the respective fields under the workers section. In case of configuring the field under workers section, without configuring different values under workers.celery or workers.kubernetes sections, it will result in applying the change to both worker types. I added comments about deprecation to every field which was used only by one executor type. Also, I implemented the separation of service accounts used by pod-template-file and Airflow Celery workers with the usage of workers.useWorkerDedicatedServiceAccounts flag. By default, both workers will use a single common service account, and the fields workers.celery.serviceAccount and workers.kubernetes.serviceAccount will have no effect.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[Miretpl]

Currently, the introduction of workers.celery section should be fully finished.

[Miretpl]

Both sections workers.celery and workers.kubernetes should be finished. I would appreciate any help with tests, due to the number of changes in the PR.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

[Miretpl]

Not stale - I'm during rebase 😄

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.