Support defining custom Roles/ClusterRoles and bindings for CRDs

### Description Currently, the Airflow Helm chart provides a fixed set of RBAC templates, such as job-launcher-role and pod-launcher-role, to support standard features. However, there is no native mechanism in values.yaml to inject custom Roles or ClusterRoles required for third-party resources. I propose adding support for defining arbitrary Roles, ClusterRoles, and their respective bindings via the Helm chart configuration to extend the permissions dynamically. ### Use case/motivation Users often use operators like `KubernetesCreateResourceOperator` to orchestrate custom resources (CRDs) for AI/ML workloads, such as RayJob (KubeRay) or PyTorchJob (Kubeflow Training Operator). Since the default pod-launcher or job-launcher roles do not cover API groups like ray.io or kubeflow.org, the Airflow Worker fails to create these resources due to permission errors. Currently, users must manually apply extra RBAC manifests or maintain a wrapper chart to grant these permissions. Allowing users to define these rules directly in values.yaml would greatly simplify the deployment of Airflow as an orchestrator for Kubernetes CRDs. Additionally, it would be beneficial to support ClusterRole and ClusterRoleBinding configuration as well, for use cases where cluster-wide permissions are required (e.g., watching resources across all namespaces). Example Configuration: ```YAML rbac: extraRoles: - name: "ray-job-role" rules: - apiGroups: ["ray.io"] resources: ["rayjobs"] verbs: ["create", "get", "list", "watch", "delete"] extraRoleBindings: - name: "airflow-ray-binding" roleName: "ray-job-role" serviceAccount: "airflow-worker" # Similarly for ClusterRoles extraClusterRoles: [] extraClusterRoleBindings: [] ``` ### Related issues _No response_ ### Are you willing to submit a PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/a…