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.
@thockin @smarterclayton Moving discussion here from https://github.com/smarterclayton/kubernetes/commit/d695810e1ca5419c02b86db14243ffe3113f58b4.

We need 3 things:
1. Object extensions, such as for volume plug-ins -- #1239 
2. Extensions that are new API objects -- #991 
3. Annotations for consumption by third-party tools and systems -- #1201 

We don't want to version all sub-parts of the API independently. That would be a mess.

I don't feel too badly about just saying the convention should be that the version is part of the extension type name. That would leave it up to the cluster operator which versions to support -- they could just install plug-ins for multiple versions, if desired. Extensions are going to be inherently less portable, anyway.