Use correct controller imports for Kubernetes native APIs

[joelanford]

Feature Request

Is your feature request related to a problem? Please describe.
When using operator-sdk add controller to create a controller for a native Kubernetes API, the scaffolded controller code contains an import for a non-existent API package.

Describe the solution you'd like
The operator-sdk add controller command should support the creation of a controller for a native Kubernetes API without requiring the user to make manual changes to the scaffolded controller code's imports.

Ideally the operator-sdk could determine whether the API version is a native Kubernetes API and use the correct import automatically, but additional flags may be required to handle ambiguous cases.

[estroz]

From #928:

If we're going to support adding controllers for kubernetes-provided API we should require a --k8s-api boolean flag be passed to add controller. Additionally an optional --k8s-import-path flag would be nice for API import paths with multiple domains or that are different than k8s.io/api. By default we can assume k8s.io/api since this will be the use case most of the time.

I'm also thinking we should version the controller package, as we can have multiple versions of the resource being reconciled, ex. v1.Deployment and v1beta1.Deployment. The three versioning strategies I see as reasonable to employ, in order of preference, are as follows:

1. canonical API versioning, ex. pkg/controller/deployment/{v1,v1beta1}.Deployment
2. package versioning, ex. pkg/controller/deployment_{v1,v1beta1}.Deployment
3. file and type versioning, ex pkg/controller/deployment.{Deploymentv1,Deploymentv1beta1}

[estroz]

Controllers are version independent by default so the above comment is irrelevant.