kontrol: dynamic changing kontrol URL support via discovery endpoint layer

This is still an proof of concept. This change is fully backward compatible with the current approach. Please read the following for the problem and the proposed solution. 

Problem: Kontrol puts it own url with the key name `kontrolURL` into the `kite.key` for every user that registers the machine. But that's a problem when the kontrol URL is dynamic and changing based on the environment. Or if kontrol is a part of a set of clusters behind a single domain (load balanced) that is appearing/disappearing based on the load. The current `kite.key` with `kontrolURL` approach fails here.

Solution: There will be a fixed kontrol running behind a domain that provides a `discovery` endpoint for others. This discovery kontrol uses the same etcd backend as with the current running kontrol. Every kontrol that runs already registers themself to `etcd` backend and is being queryable. Therefore we use the existing feature by  introducing two new `claims` in `kite.key`:

* discoveryURL
* discoveryID

Now it's up to a kontrol instance whether to use a discovery endpoint or not. That is defined by setting the `DiscoveryURL` and `DiscoveryID` fields in the Kontrol struct. If set, kontrol adds a unique discovery id and the disocvery endpoint to the `kite.key` too (together with their current URL). A remote `kite` now does the following:

* Read the `kite.key` and parse all values into config struct (same)
* If Kite decides to use `Register()`, `GetKites()` or `WatchKites()` initialize a kontrol client that is talking with a remote kontrol (same)
* Now before connecting via the default `kontrolURL` check whether the kontrol passed a `discoveryURL`, if yes connect to the remote kite defined with the `discoverURL` and make a query call to the `getKites` with the kontrolquery containing the `discoverID` (new). This remote kontrol at `discoverURL` is going to return the correct kontrol `url` associated with the `disccoveryID`.  Connect to the remote kontrol with this URL
* If there is no `discoveryURL` use the default `kontrolURL` defined in the `kite.key` (same)

As seen we introduced a new step which interferes and replaces the kontrolURL. It's an optional feature and only is executed if the remote kontrol provided the `discoveryURL` and `discoveryID` values within the `kite.key`. Therefore it's fully backward compatible. 

This PR also adds a new feature to the `client` package called `URLFunc()` which is used to also handle reconnection cases. If a Kite uses the discovery to connect to a `kontrol` and there is a disconnection, it doesn't reconnect again to the same URL. Instead it again asks to the discover endpoint and retrieves a new URL.

All tests are passing but we need an additional integration test. Please do not merge until we decided this is a good approach.