Break up API client into per-resource client and common code

Refactor client code into per-resource client objects and a common client core. The purpose of this is to allow future composition of clients that access both Kubernetes resources as well as plugin custom resources.
It may not be necessary to split each of these as granularly - it might be ok to say that a client that knows about any of  pods / replication controllers / services is assumed to know about the others.  I feel like version client might actually be better if it was coupled to an api version, in case a consumer decided to unify a set of apis behind a proxy.  In which case we could return an api description object from /api/v1beta1 that listed the resources supported and also returned version info.  That's a separate concern though.