Secure paths exposed through proxy with TLS

This is a follow-up of #6446 .

Currently paths exposed with the `expose` stanza do not support authentication/encryption with TLS.

Ideally this feature would support two things:
- **One-way TLS authentication** where Envoy would authenticate the external service making requests to the path (but not vice-versa).
- **Mutual TLS** where both Envoy and the external service are authenticated.

To support mutual TLS for each path users need to specify a:
- **CA cert**, signed by a CA that also signs the certificates of applications making requests to the path.
- **Client cert and key**, for Envoy to provide during the TLS handshake.
- **tls_skip_verify flag**, to skip TLS verification

To authenticate/encrypt traffic to specific paths should be fairly straight forward.

An area that needs more thought is how to automatically encrypt traffic for Consul's health checks, given that the Consul agent will not have a client certificate unless it was provided (manually or with auto_encrypt).

However, that could be skipped altogether by requiring that the agent must be provided with a client certificate if a user wants to encrypt traffic to paths exposed with `expose.checks`.

There is a WIP branch with these changes here:
https://github.com/hashicorp/consul/tree/expose-paths-tls

That branch includes the required flags, and an un-tested first pass at configuring a TLS context for Envoy.