VXLAN overlay networking

This patch adds an overlay network using VXLAN so that every container has a cluster-routable IP address without relying on any specific networking technology being available.

A [modified version](https://github.com/coreos/flannel/pull/108) of the flannel daemon from CoreOS is used, which allocates subnets and communicates with other members of the cluster using etcd.

- Remove iptables port forwarding; iptables is now only used for
  NAT'ing outbound external traffic. If jobs want to receive inbound
  traffic from services that are not routable via VXLAN, they must
  use the host network namespace.
- Add flannel to the layer 0 bootstrap manifest.
- Add a networking setup stage to backend implementations, currently
  this is hard-coded to be run after the flannel job is started in
  the manifest runner. In the future it will be more abstract.
- Add a networking setup implementation to the libvirt-lxc backend
  that knows what flannel is and configures everything properly.
  This stage replaces the networking setup in the backend
  initialization:
  - Wait for the flannel job to come up.
  - Wait for the configuration from flannel to become available.
  - Parse the configuration from flannel, this config has the subnet
    and bridge MTU.
  - Configure the libvirt network/bridge with the appropriate
    settings.
  - Enable outbound NAT via iptables.

Closes #423
Closes #275
Does every added listener have to manage deferring its own cleanup like this?

If it's just waiting for worst-case scenario cleanup on job death... is there such a thing as a listener that *won't* want to be discarded in that case?  If (if) we could just toss all listeners in that case, then we could skip parking a goroutine for the lifetime of the job.