Tolerate non-openshift servers on oc commands better

[smarterclayton]

A number of failures can be better handled when oc commands are run against a Kube server.

• Version fails to report server (fixed in 1.3)

• It should be possible to oc login <kubeserver> --token or provide basic auth credentials

• import-image doesn't recognize a generic error response for post imageStreamImport correctly as "not supported"

• status should gracefully degrade (will open PR)

• new-app and other "bulk" creation commands return ugly errors:

  error: unable to recognize /__internal, Kind=ImageStream: no matches for /, Kind=ImageStream
  error: unable to recognize /__internal, Kind=DeploymentConfig: no matches for /, Kind=DeploymentConfig
  

  those errors should be prettier

• policy commands give ugly errors:

  $ oc policy can-i read pods
  Error from server: the server could not find the requested resource (post subjectAccessReviews)
  

  We should probably have a better message - "the server does not support the resource subjectAccessReview (post)" and we should also handle that specific error on the client:

[{
  "metadata": {},
  "status": "Failure",
  "message": "the server could not find the requested resource (post subjectAccessReviews)",
  "reason": "NotFound",
  "details": {
    "kind": "subjectAccessReviews",
    "causes": [
      {
        "reason": "UnexpectedServerResponse",
        "message": "unknown"
      }
    ]
  },
  "code": 404
}]

[smarterclayton]

@ncdc @liggitt started trying to run more commands.

[smarterclayton]

Going to add a test case that runs certain commands against a apiserver/etcd pod.