Failure lockout when starting up Agent using two different bind addresses

If you start up an agent with one bind address, say:

```bash
consul agent -server -bootstrap -data-dir=/tmp/consul -bind=127.0.0.1
```

*Note:* does not have to be bootstrapping.

and then gracefully shutdown that agent and attempt to bring it back up with a different bind IP (say, as in my case, you made an error or didn't specify a bind address originally):

```bash
consul agent -server -bootstrap -data-dir=/tmp/consul -bind=172.20.20.10
```

The agent's raft goes into a spin throwing RPC errors:

```bash
2014/04/17 20:52:17 [ERR] agent: failed to sync remote state: rpc error: No cluster leader
    2014/04/17 20:52:17 [ERR] agent: failed to sync remote state: rpc error: No cluster leader
    2014/04/17 20:52:17 [WARN] raft: Heartbeat timeout reached, starting election
    2014/04/17 20:52:17 [INFO] raft: Node at 127.0.0.1:8300 [Candidate] entering Candidate state
    2014/04/17 20:52:17 [ERR] raft: Failed to make RequestVote RPC to 192.168.0.191:8300: dial tcp 192.168.0.191:8300: connection refused
    2014/04/17 20:52:18 [WARN] raft: Election timeout reached, restarting election
    2014/04/17 20:52:18 [INFO] raft: Node at 127.0.0.1:8300 [Candidate] entering Candidate state
    2014/04/17 20:52:18 [ERR] raft: Failed to make RequestVote RPC to 192.168.0.191:8300: dial tcp 192.168.0.191:8300: connection refused
```

and will not allow another node to join because it is trying to reach a consensus on a leader with itself. So the other node is thrown into an error loop of:

```bash
2014/04/18 15:29:22 [WARN] raft: Remote peer 172.20.20.10:8300 does not have local node 172.20.20.11:8300 as a peer
```

After looking through the code a little bit, this seems to be related to how peer list persistence is handled. Here, both 172.20.20.10:8300 and 127.0.0.1:8300 exist on the peer list upon boot which causes Raft to try to connect to that impossible node in it's Candidate process because Raft assumes there are enough nodes for consensus.

According to the Raft docs, if this were the case in which the other node just didn't exist anymore, the correct procedure would be human intervention.

Quick Fix: Delete the `data-dir` to eliminate the old peer list if this mistake is made.

I attached some code that would remove all local addresses with the same port from the peer store before adding itself to the list on bootstrap. This would be a convenience since we can't operate two nodes on the same instance bound to the same port anyways, reducing the need for human intervention in the event of a mis-configuration. It also has the added benefit of preventing people trying this out for the first time, such as myself, and making this mistake getting frustrated before they find out how cool this thing is!