Provide the minimal connect setup in non-connect endpoints.

#### Feature Description

Provide the minimal connect setup in non-connect endpoints.

#### Use Case(s)

At integrating Consul-Connect natively in a load-balancer, I'm struggling with the existing endpoints.
* `/v1/health/service/foo-bar` returns a service but don't tell me whether it has a connect definition or not
* `/v1/health/connect/foo-bar` in fact returns me the equivalent of `/v1/health/service/foo-bar-sidecar-proxy` and actually returns nothing/empty if the service I'm requesting is not connect-enabled.

When watching endpoints to provision all services, including connect services, I have two options:
* watch concurrently /v1/health/service and /v1/health/connect, and manage all the pain associated to reconciliation of events, occurring on both endpoints, with potential delays between first and second event, etc.
* watch only /v1/health/service, force my users to add a "connect" tag, then add custom business logic on my side to deduce that I should fetch /v1/health/connect in addition, so that I can finally retrieve the connect IP+port (which is suboptimal).

I was wondering why all the connect config is [actually removed from the newly registered service](https://github.com/hashicorp/consul/blob/e7db6135f9a641952e660a8cb7dcd4ad7a67aa6f/agent/agent_endpoint.go#L980-L984).

To me, the connect endpoint gives a "connect-first" approach, where for ex. the Service.port is the connect one.
```
"Service": {
"Kind": "connect-proxy",
"ID": "foo-bar-sidecar-proxy",
"Service": "foo-bar-sidecar-proxy",
"Port": 21001,
```
But still you have the downstream information available:
```
"Proxy": {
"DestinationServiceName": "foo-bar",
"DestinationServiceID": "foo-bar",
"LocalServiceAddress": "127.0.0.1",
"LocalServicePort": 80,
"MeshGateway": {},
"Expose": {}
},
```
#### Proposal

Can't we have the opposite as well with /v1/health/service? Such as:
```
"Connect": {
"ProxyServiceName": "foo-bar-sidecar-proxy",
"ProxyServiceID": "foo-bar-sidecar-proxy",
"ProxyServiceAddress": "192.0.2.1",
"ProxyServicePort": 21001,
},
```
This would allow an event consumer to guess that a connect equivalent exists, and to grab its IP+port directly.
Maybe other properties would be interesting as well, but I've no use-case for now to identify which of them would make sense.