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.  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 better composition for clients?

* 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
* Break the coupling between the api package and etcd_tools / watch - instead, they use an Encoding interface (Encode/Decode/DecodeInto), which coincidentally the apiserver also can use
  * In practice, most uses of API are the encoding decoding interface.
  * APIServer provides deserialization, so RESTStorage doesn't have to (removes some flexibility, but since types already needs to own format conversion...)
* 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?).
* Moved watch streaming from tools to apiserver (clients can then import apiserver and be able to stream events)

Open questions (@lavalamp @erictune):
* Is a singleton global type registry bad, good, or neutral?
  * Opinion: Bad - would prefer the global registry be something created and passed in to an APIServer as n encoding/decoding interface, and that the set of registered types is also defined at point of use (apiserver, client) via an explicit operation.
* 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, just interfaces.  Defining an apiserver on v1beta1 implies that you need to pick a serialization for status for v1beta1 - but it's the callers responsibility to version those as part of their API

Will break this up into smaller changes as necessary.