WIP - Allow kubectl to handle arbitrary objects

Kubectl will need to handle extension for known (part of api.Scheme) and unknown (defined via config or future ComponentPlugin extension mechanisms on the api server) object types.  This pull request:

* updates the create/update/delete flows for kubectl to separate the versioning abstractions from the core code path via interfaces
* decouple kubectl commands from knowing about specific details of objects (via RESTMapper and the Factory abstraction for commands)
* factors `pkg/kubectl` to ensure it uses our existing abstractions for versioning and object types
* adds more test cases to core paths
* ensures that output from `kubectl get` goes through external versions
 * defaults to `latest.Version`
 * can be changed via `--output-version`
* add more test cases to `hack/test-cmd.sh` for the command output flows

A key goal of the pull is to continue to refine the runtime / meta abstractions to assist in client logic, and to allow other consumers of kubectl to support more than just types in api.Scheme (openshift).

A follow on pull will address the limited unit testability of the `pkg/kubectl/cmd` package.

Note: first commit is in #2059
They did so before, I just carried it over.  Agree it's not fully thought through.


> On Nov 3, 2014, at 7:09 PM, bgrant0607 <notifications@github.com> wrote:
> 
> In pkg/kubectl/cmd/create.go:
> 
> >  			checkErr(err)
> > +			fmt.Fprintf(out, "%s\n", name)
> Why are these routines printing out the names now? Similar pattern to docker CLI of printing container ids? Perhaps we should be printing fully qualified names (e.g., URLs containing namespace, etc.) instead?
> 
> —
> Reply to this email directly or view it on GitHub.