Proposal: v1beta3 API overhaul

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

EDIT: Moving to higher bandwidth document here: https://docs.google.com/document/d/1E_HNsbyocweD9zJHXbz5Xb9XPwBqvDnLHhGeBq15FlI/edit?usp=sharing

> > +APIs SHOULD set resourceVersion on retrieved resources, and support PUT
> > idempotency by rejecting HTTP requests with a 409 HTTP status code where
> > an HTTP header `If-Match: resourceVersion=` or `?resourceVersion=` query
> > parameter are set and do not match the currently stored version of the
> > resource.
> 
> @lavalamp can correct me if I'm wrong, but my understanding is that we use
> resourceVersion from the object that is PUT as the precondition. It's a
> little tricky to track down, because I think we rely upon etcd for
> enforcement: pkg/tools/etcd_tools.go#L240.
> 
> I guess that is a little awkward, since we're (presumably) not actually
> setting the field to that value.

I think anywhere we use AtomicUpdate which calls into bodyExtractObj (most updates) we don't explicitly bail out if the value isn't the same.

We should probably open an issue to track codifying this - both the "only continue if my version exactly matches" and the "ensure we're both working from the same original value".