Use config sources for Kubelet, switch to podFullName

As discussed in #297 and also a side discussion about abstracting the Kubelet from being directly dependent on etcd, start refactoring config service to decouple sources of config from sync loop and switch from Manifest.ID -> Pod Full Name in the Kubelet.

Simplifies the Kubelet Run() step by requiring configuration to be defined up front, and an update channel passed into the Kubelet.
The distinction between a pod and a manifest is fuzzy to me.

When we read a config file or config URL - what object type are we expecting to find?  Pod or Manifest?  If it is pod as specced by this PR, then it is no longer compatible with the existing structure (all container VMs, for example, specify a manifest).  I assumed that we would keep manifest as the fundamental type for Kubelet, adding new fields there, possibly renaming it to pod for kubelet use.

Am I making sense?  I admit there's some fuzziness for me here..