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
A single apiserver shares an encoding/decoding interface.  By implication, when you initialize an APIServer you're explicitly stating all of the objects in that APIServer should be at the same version (by virtue of prefix) - the encoding provided should default to returning objects in whatever serialized form is preferred.  So the v1beta1 endpoint should be initialized with `api.New("v1beta1", apiserver.AddTypes, // ... all supported types of api v1beta1)` for its types.

As a consequence, apiserver.Status / Watch / ServerOp types (apiserver.AddTypes) must be added to the api.New call as well or they won't be serialized.  So not terribly different than today.  Difference is that etcd code doesn't need to know about Status/Watch/ServerOp (it's not persisted) and the consumer of the apiserver types gets to choose what version of apiserver types to expose on their version.