Support node replicas in `/api/v2/monitor/health` response

### Description Modify the `/api/v2/monitor/health` response to surface information for the state of any horizontally scaled / replicated components. Given that all the components described in the current response are horizontally scalable, It would be much more useful to return a list of state payloads for each component. For example, in a high-availability scheduler setup running 2 schedulers, it would be useful to see the status information for both those two schedulers in the response. A very rough outline of what the proposed API response _might_ look like is below: ```json { "metadatabase": { "status": "string" }, "scheduler": [ { "hostname": "scheduler-1", "status": "healthy", "latest_scheduler_heartbeat": "scheduler-1 latest heartbeat here" }, { "hostname": "scheduler-2", "status": "healthy", "latest_scheduler_heartbeat": "scheduler-2 latest heartbeat here" } ], "triggerer": [ ... ], "dag_processor": [ ... ] } ``` Concretely, I believe the most noteworthy changes necessary for this would be: 1. Adding a `hostname` field to the `(Scheduler|Triggerer|DagProcessor)InfoResponse` models in `airflow.api_fastapi.core_api.datamodels.monitor` 2. Changing the fields of `HealthInfoResponse` model to be a list of the corresponding per-field models. 3. Adding an index on the `hostname` column in the `jobs` table (this particular change would benefit a number of other things unrelated to this ticket). ### Use case/motivation Currently, as of [version 3.1.7](https://airflow.apache.org/docs/apache-airflow/3.1.7/stable-rest-api-ref.html#operation/get_health), responses from the `/api/v2/monitor/health` endpoint offer a single `status` and `latest_*_heartbeat` field per Airflow component. This is fine for any Airflow deployment which has a single scheduler, a single triggerer, and so on. However, the information from this endpoint does not provide reliable insight into the system's health if one …