Prepare for external scheduler

1. Add more Pod statuses. Expectation that PodStatus will get changed by
   future scheduling actuator API, indicating acceptance/rejection of
   pod.
2. Store assigned host in etcd.
3. Change pod key to /registry/pods/<podid>. Container location remains
   the same (/registry/hosts/<machine>/kublet).
Thanks Brian, I thought you might have something to say about this PR. :)

Two comments:

>Synchronous vs. asynchronous admission control and/or scheduling: Synchronous is easier for users to deal with, but asynchronous provides more flexibility and transparency to higher-level infrastructure layers. A synchronous interface can always be layered upon an asynchronous API, on the server or in libraries, UI, CLI, etc. If asynchronous, that's where it becomes necessary to represent that the request is awaiting an external dependency to be satisfied.

k8s currently has such a set up (asynchronous API, but with timeouts and if needed, polling client-side to make it synchronous).

> Interface with scheduler: Did this PR imply that the interface should be implicit through the shared state in etcd? Let's not do that. Let's hash out a real API, here or elsewhere.

No, I wasn't intending to make a shared-state interface; I don't plan to have the scheduler talk to etcd at all. I'll make a PR with an explicit scheduler interface soonish.