Add the consul_service_health data source

[remilapeyre]

This PR adds a new data source consul_service_health that fetch checks information about a given service.

See #87

[remilapeyre]

I wish I would be able to export attributes as sub-resources so they would be accessible like so:

${data.consul_service_health.vault.nodes.0.service.id}
${data.consul_service_health.vault.nodes.0.service.name}
${data.consul_service_health.vault.nodes.0.service.tags}
${data.consul_service_health.vault.nodes.0.service.address}

but it seems to me that this is not possible so I had to resort to an ugly _:

${data.consul_service_health.vault.nodes.0.service_id}
${data.consul_service_health.vault.nodes.0.service_name}
${data.consul_service_health.vault.nodes.0.service_tags}
${data.consul_service_health.vault.nodes.0.service_address}

[remilapeyre]

To correctly test this PR, it is better to wait for the merge of #64

[paultyng]

Will this let you wait until a service is healthy? For example if you just created a new service in the TF script and wanted to wait for it to be fully available?

Maybe an optional way to use this, with a timeout?

[pearkes]

It looks like this is two changes:

• Changes to retrieving health checks
• New consul_service_health data source

On the new data source, I could see certain users getting tripped up on the use-cases here – really this will change so much that it feels a bit strange in the context of Terraform, but I also understand there may be good potential use-cases for then getting Terraform to do other things with the healthy service addresses. I just wonder a bit if we're encouraging strange things by providing this highly mutable endpoint.

On the other hand, this is an opt-in data source and given it is not overwriting / writing data I don't see much downside harm in including it for those users who do have use-cases that are in need of this particular thing.