Implement pluggable discovery adapters and standalone tests

This pull request adds a `Locator` interface for server discovery, extracts the etcd discovery implementation into an `EtcdLocator`, and adds a `StaticLocator` adapter. The config loading mechanism has also been refactored, making it possible to run the tests without etcd, memcached, or a standalone Simple Push server.

* The router now uses a buffered channel (`bucket_size`) instead of partitioning contacts into buckets.
* The etcd key prefix and minimum refresh interval are exposed as `EtcdLocatorConf.Dir` and `.RefreshInterval`, respectively.
* `EtcdLocator` now uses the normalized key (prefix + hostname) consistently, and accounts for non-default HTTPS ports when constructing the key.
* The `PluginLoaders` map associates plugin types (i.e., logger, proprietary pinger, metrics, storage adapter, router, locator, server, and handlers) with initialization functions. This is used by `TestServer` to specify configuration options programmatically. The `*Conf` structures have also been flattened where appropriate.
* The `Host` and `Port` options have been consolidated into `Addr`. If `Addr` is omitted, the server and router will listen on random ports.
* `Server` and `Router` now initialize their own `net.Listener`s, avoiding a race condition where the tests would begin running before the server was ready.

Closes #30. @bbangert, @jrconlin, @rafrombrc r?
Yeah, I see what you mean. So, I understand, the lynchpin here is ```net.Listener```, we use it [in app](https://github.com/mozilla-services/pushgo/pull/71/files#diff-3c32a1673a16ff43029882b01713edefR153), and then later [in router](https://github.com/mozilla-services/pushgo/pull/71/files#diff-0ee0f30fea9ceb968279676779403415R163) where we get the IP and Port, right? (By the way, you've got [a getter](https://github.com/mozilla-services/pushgo/blob/feature/pluggable-discovery/src/github.com/mozilla-services/pushgo/simplepush/router.go#L189) for ```.listener``` in Router, and another in Server.) Server uses ```.listener``` the same way.

I'm not really seeing anything aside from that pattern. I'm guessing the real reason we're duplicating this code is for the TestServer stuff. Is there another reason we're duplicating the code? 

I'll admit that it's probably a bit crappier, but I'm wondering if a more compliant method might be to pass the actual http handler as an argument so we can just hand a mock'd version to the tester.