hack endpoint controller so that services map to hostIp:hostPort

... instead of podIp:containerPort

This is a hack and was meant to be a temporary thing to validate that we can run the guestbook examples (with modified, mesos-friendly ports). It deviates from default k8s functionality to simplify networking requirements for k8s-mesos cluster.

Instead of a k8s service endpoint mapping to a `podIP:containerPort` it maps to `hostIP:hostPort`. This means that for any service that wishes to expose pod services, those pod services must specify a hostPort in their manifest. Leaving hostPort blank or set to zero in a pod manifest will result in no hostPort being mapped to the pod's containerPort and so services will be unable to connect.

A significant consequence of this is that end-users publishing pods are more likely to collide on hostPort's since they must specify them in order to expose pod functionality through services. A possible workaround (*currently unimplemented on this branch*) would be to allow the k8s-mesos scheduler to randomly assign hostPort's to pods if users publish a pod/container that specifies "magic" hostPort of 1. Ugly, ugly, ugly but it makes life simpler for end-users at the expense of a lost port (since 1 is magical now).

Use this branch at your own peril for now.
Is it really okay to return nil for cloud.TCPLoadBalancer and cloud.Zones? Should we be redirecting to the k8s interface, or doing something real here? Maybe at least a TODO/issue?