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).
@smarterclayton  Being out of space can be a temporary condition, like if some machines are temporarily removed from the cluster due to an error, but will be replaced soon.

So, is the right behavior to accept the request and keep working on it, or to reject the request after some amount of time?  The former has the advantage that client code does not need to retry in the case of a temporary shortage of machines. 

On the other hand, if the client is never going to succeed without changing something external to the system (auth failed, or not enough quota, etc) then a prompt rejection makes sense.  

Thoughts?