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.
Agree there's fuzziness.  Everything in the PR is API compatible with before the PR, so no changes *should* happen.

Keeping manifest for fundamental etcd -> kubelet communication isn't terrible, but I think the id in the manifest is misplaced / misnamed.  Manifest feels like a "description", pod feels like "resource" because it has a name / id.  I think I would make the argument that the "pod" resource is what should be the API interaction with the kubelet, but defined in a way that makes it clear that the kubelet is going to craft a full name for that pod and that the source is not in total control of kubelet.