DNS and HTTP API Discovery Chain support

Consul 1.6.0 introduced a new "Discovery Chain" for configuring mesh routing. The design was for this discovery chain to apply to both Connect but also be the basis for DNS/API based discovery going forward too. This was based on several user asks from last year requesting central control of failover for DNS and API-based discovery.

Traditionally the split between service and prepared query has made it impossible to reconfigure traffic centrally as all clients need to update DNS from .service.consul to .query.consul which was often impractical. Also after switching, users lose the ability to use blocking-based API discovery options like consul-template for those services and have to poll for changes instead.

There are a bunch of subtleties about changing how API/DNS discovery works and we may need to do it in phases (make it opt in at first for DNS and separate endpoints in API). The goal is though that all current use-cases of Prepared Queries would be covered by "transparent" control through the discovery chain.

Other unknowns to figure out here are how to support explicit client control e.g. wanting to hit only the master instance by tag/meta or having some clients that explicitly want to route to another DC while the default is to use local version and only failover to another DC. i.e. replacing and/or handling DNS requests with tag and/or datacenter specified. "Virtual services" are one option here where you create Discovery chain configs against a service name that doesn't actually have instances registered but allows the required routing to be setup, but some of the UX of that might be a bit gross - perhaps we can make it more first-class?

Other aspects of this are things like making sure our Connect documentation and guides stop using prepared queries and start using Discovery Chain everywhere etc.