Consolidated health check service

### What should we add or change to make your life better?

YARP can do active health checks against backend servers to make sure that they are able to respond successfully to requests. In the case of having a number of YARP proxy instances, and a large number of backends, each YARP instance will need to ping each back end for health checks. As the number of servers grows, the health checks will also grow, potentially exponentially.

For scale out scenarios, YARP should have the ability to run the health check as a separate service. That should be runnable on a limited number of servers, which will perform the health checks and then provide the data to other YARP instances.

### Concept

YARP includes a consolidated health check service which can be configured to run on a server or two. This service will talk to the configuration server #1710 to understand the cluster and destination definitions. It will perform the active health checks against the servers based on the URL definitions in config.

The configuration service will act as a broker, enabling instances to discover each other:
* The health check service will register with the configuration service telling it of its presence
* YARP proxy servers will get the address of the health check service from the configuration service. They will use its active health check data to determine which sites are unwell.
* YARP proxies will continue to use passive health checks against backends. If/when they determine that a backend is likely unhealthy, they will notify the consolidated health check service.
* The health check service will make a determination if the destination is healthy, so that one bad YARP instance can't DoS the entire system.
* If there are multiple health check servers, then they will inform each other of health changes. Similar to notifications from destination servers, it will make its own determination on actual the health status.

### Proposal

Consolidated health checks will be dependent on having a configuration server. This features value is mostly when used in a scale out scenario where there are multiple YARP instances. The configuration server will provide the orchestration of YARP instances knowing about the health check server, and also for the health check server knowing about the configuration of the clusters and destinations.

The configuration server will include configuration data about the health checks as part of the configuration that is exposed via rest endpoints, and notifications in either direction about a specific destination's health.