Discovery Service backends token/etcd/file

This is an initial version, feel free to comment.

Replace the `--token` flag by a more generic `--discovery` flag supporting multiple backends. See https://github.com/vieux/swarm/blob/discovery/README.md for more info.

token
-------
Basic usage: `--discovery token://XXXXXXXXXX` (replace `--token XXXXXXXXXX`) works for both `join` and `manage`
you can also use your own service implementing our discovery api: `--discovery discovery://example.com:5000/XXXXXXXXXX`

etcd
-----
If you already have your own etcd, you can use it with `--discovery etcd://example.com:5001/XXXXXXXXXX`
in both `join` and `manage`

file
----
You can also use a static file describing your cluster like this 
```
192.168.0.1:2575
192.168.0.2:2575
192.168.0.3:2575
```

Then use `--discovery file://path/to/file`.
In this static setup, join makes no sense, so you only have to use this in `manage`

Note: `swarm create` make sense only when you are using `token://`

close #145
You might consider at this team to future proof the API by returning a []struct, even if it's as simple as

```go
struct RegisteredNode {
    Url string
}
```

I could see very quickly that we would need to return a state.  The binary approach of there/not there is not really sufficient for more complicated scheduling.  For example other states could be "unknown", "inactive", "failed".  "unknown" would mean that you can't schedule new tasks on the node but also don't know if the existing tasks are still running.  "inactive" would mean tasks are still active on the node but no new tasks should be schedule.  "failed" would mean the node has failed, but non-ephemeral tasks should not be rescheduled as the node may be repaired and brought back online.

I think the discovery service should provide the node state because the discovery service could use out of band means to determine the state of a node that the scheduler could not do.