Change ClientAddr to default to BindAddr when not present.

[sean-]

With this change, it is now possible to only specify the -bind or
bind_addr attributes and get a functioning consul agent.

There are two possible paths from this PR:

1. Set BindAddr's default to {{ GetPrivateIP }}, which will return an empty string and fail downstream if a private IP isn't available.
2. Leave things as the status quo for the time being until we move to something that's 100% backwards compatible.

I researched option #2 but put a pin in that because it brought a pile of additional work. The rough sketch of what I had in mind to satisfy option #2 would be to:

• introduce a -listen flag and config option which would contain one or more IP addresses that would be used for all services.
• introduce similar -listen-http, -listen-serf that would be the more granular per-service overrides, but similar to -listen, also zero or more.
• deprecate -advertise-addr and -advertise-addr-wan and tagged addresses
• introduce a mapping scheme that would allow for NAT'ing Consul's various addresses before values are either queried or leaked into Consul/Serf. This was the biggest lift, but it simplifies the UX considerably.

The thought experiment went like this (JSON5 used in this example for comments-sake):

{
  // or simply "nat"
  "nat_rules": {
    "dc": {
      // Like _agent in prepared queries, _dc would be an alias for the current datacenter.  In this case, any query for the http or https services would be static NAT'ed to the following two endpoints.
      "_dc": {
        "http": "1.2.3.4:8600",
        "https": "6.7.8.9:8600"
      }
    }
    "agent": {
      "node1": { /* node1's override */ },
      "*._dc": { /* I contemplated a glob and removing the agent nesting... */ },
    },
  }
}

But again, that was a big lift potentially and it was easier to just set two defaults. It'd be nice to clean this all up in a unified manner, however, and a thrust in this direction seemed like a reasonable approach.

Regarding the PR, I considered a fallback to 127.0.0.1, but that never seemed like a good idea in a normal production environment. If someone wants 127.0.0.1, they should explicitly set it. Merge or discard as you see fit.

[slackpad]

Looks like a good way forward for now - we definitely don't have time to make a larger change for the 0.8 release. One note on the docs and otherwise LGTM.

[slackpad]

Can you qualify these with "in Consul 0.8 or later this is X, and previously it was Y".