Thought Experiment - Invert types from global to local, remove api singleton methods

EDIT: This doesn't compile totally, just enough to demonstrate the removal of api as a singleton

Removes the singleton for API KnownTypes.  Not complete, mostly because the Watch deserialization mechanism depends on static access, and also because of the etcd_tools dependency on deserialization.

I wanted to play around with the question: can the implicit API type singleton factory (and global namespace of api types) be split in a way that allows easier reuse:

* Moves api/types.go to api/internal/types.go (but it should really probably be `api/podapi/types.go`, with `api/podapi/v1beta1/types.go`)
* Moved Status/ServerOp/Watch to apiserver/types.go
* Added a bunch more abstractions - etcd_tools expects a Decoding/Encoding abstraction (so its not coupled to api)
  * In practice, most uses of API are the encoding decoding interface.
* See [cmd/proxy/proxy.go](https://github.com/GoogleCloudPlatform/kubernetes/pull/742/files#diff-046c74e5f16488bbad2362f4da7cbc8eR58) for an example of initializing an api with `api.New("", internal.AddTypes)`.  There could of course be helpers for creating that consistently, but they probably belong either in podapi (import all sub types) or separate (so different clients can choose what apis they support?).
* Most of watch is better off in apiserver/, although it could be apiserver/apitypes/

Open questions (@lavalamp @erictune):
* Is a singleton global type registry bad, good, or neutral?
  * Opinion: Would prefer the global registry be something created and passed in to an APIserver as a serializer interface or underneath, and that the set of registered types is also defined at point of use (apiserver, client) via an explicit operation.
* Should api.Status, Watch, and Operations be part of apiserver?  Do they need to be versioned?  
  * Opinion: they're only weakly coupled with what's in api/, they should be "owned" by the apiserver package and the generic API client.
* Should apiserver depend on "the api pkg + types", "the api pkg w/o types", or "only a RESTStorage/WatchStorage implementation"
  * Opinion: apiserver should not depend on types outside of its package, and preferably everything else should be an interface passed with RESTStorage / WatchStorage.  Watch should just work with the serialization of the associated RESTStorage
* Operations is already something that won't work behind a load balancer as is - should this be moved soon to an OperationStorage abstraction?
  * No opinion
JSONBase could be part of pkg/api instead of pkg/internal - I didn't think through that much here.