Initial support to propagating the termination reasons and image failures

Resent ... :-)

I still need to fix e2e tests. Unfortunately everytime I ran e2e, it ran into a weird issue. Will update this PR once e2e is fixed.

With this PR, docker.Container is retired completely from our API. But to achieve that, I have to introduce some to be deprecated field, such as PodIP for now. Once below TODO 1) is handled, those fields will be removed. (#137)

Also why container is waiting is added in this PR. (#941) Currently only two possible causes: 
1) The request image is not ready (The reasons can be categorized into 2, one is still pulling, another one is pulling failure. Filed an issue to docker, but it should be ok for now since we already have creation timestamp, and real container state reported)
2) Failed to run the container (Current I just guess it based on available data, but a pending PR to resolve docker/docker#8294 should give us more detail information)

All those information are not comprehensive

There are many TODOs following:
1) I tried to propagate then entire CurrentState back, but that requires more changes, especially v1beta3 we retired PodState, and introduced PodStatus. We can handle that separately when starting to support v1beta3.
2) Several docker issues filed against docker, and some are fixed and should be available in v1.3 release.
3) Arbitrary termination reasons initiated by the user or management system will be handled separately through #1462
4) Need to decide how to integrate with events next to make termination reasons more comprehensive.
Hrm, this block feels complex.  How about:

if err == nil {
  containerStatus.State.Waiting...
} else if err == docker.ErrNoSuchImage {
  ...
} else {
  ...
}