Proposal: Separate desired and current states

Speculative change for some items from #1200:

* Metadata that applies to resources is split from APIMetadata on non-resource API objects
* Metadata is a sub field of objects
* Labels are on Metadata
* Pod current and desired state is split
* Name is used for pods instead of ID (UID is part of metadata, Name is part of resource) for idempotent creation #148 and #1216 
* PodTemplate is a Metadata carrying object as per #170
 * If replicationController gave way to a generic "replicator", then pod template could be both a nested struct and a real resource.
* A ScheduledPod and ScheduledPodList is what the kubelet sees as per #860
* Non-schema'd k/v values on Metadata as `Config` (better names welcome) as per #1201

Not changed yet:

* ReplicationControllers
* Services

Only look at the second commit, the first is just to get a nice diff from v1beta1.
Copying @thockin's comment from https://github.com/smarterclayton/kubernetes/commit/d695810e1ca5419c02b86db14243ffe3113f58b4: nit, maybe it is too late. We are saying "status" to mean a state in a state machine and "state" to mean "data". I'd love to reclaim PodState for "as in FSM" usage, and replace PodState with PodStatus or something. If this one goes down in flames, I'll understand. It's just that these names are bass-ackwards from internal code :)

Since I've been exposed to the same internal code as Tim, I kind of agree. State and Status are near-synonyms, though, and this seems likely to cause confusion in the future. We should use just one of these terms and pick a different term for the other use. I'm fine with PodStatus as is. Another possibility would be Condition (definition: state of something, esp. with regards to its working order). Another option is to always qualify state, such as CurrentState.