Several items from Cloud Foundry usage of Consul

Hey @slackpad, thanks for meeting with some of us from the Pivotal Cloud Foundry team, here's some of the points we talked about.
- [x] Migrate all gossip key stuff off RPC client so we don't have to use the RPC client at all to orchestrate how we start the consul binary.
- [x] Have an HTTP API endpoint for `leave` command, instead of only RPC interface.
- [x] "Stats for Raft -> consul operator healthy server replication OK CLI + API" -- so that we can simplify Consul orchestration, knowing that a server is synced rather than polling stats endpoint and comparing numbers.
- [x] "Bootstrap CLI + API -> are you in a cluster and are you synced" -- so that we can programmatically put a server into bootstrap mode instead of rewriting config and having to restart server.
- [x] Make a server leave as a first class thing.
- [x] Does leave give the right feedback? Seems like it returns before leave has happened.
- [x] Will stale Serf info add a failed server back in (do we check the health)?
- [ ] Server name change issue: https://github.com/hashicorp/consul/issues/2172.
- [ ] Client rapidly turning into a server gets ignored by other clients as a non-server.
- [ ] Gossip keys install should say who failed and why (at least the IP).
- [ ] If keys have been rotated new agents don't have the old key history - where are the keys stored? What files would they need to keep on a restart?
- [ ] Do we need a special case operator command to help with leaves (like maybe take a list of server IPs to RPC to)?
- [ ] Manual mode would need TLS configs and stuff, i.e. being able to cURL a Consul server with keys and certs, or even the `consul` CLI supporting commands to remote servers and supporting flags for TLS things -- needs to support just giving it an IP and maybe ignoring domain name verification (chicken-egg problem).

Some of the items above are maybe a bit roughly worded, we can work on refining them.

Also, please let us know how we can help on these via PRs.

Thanks!