Establish home for v1.0.0 Go APIs

[joelanford]

Goals:

1. Eliminate current and prevent future side effects of dependency imports when importing APIs. (for example: see https://github.com/openshift/enhancements/blob/master/dev-guide/api-conventions.md#no-functions)
2. Put up barriers to breaking changes. Once we reach v1.0.0, we MUST avoid breaking changes.

Breaking changes include:

1. Anything that causes the go-apidiff job to fail. (see separate issues related to moving non-API Go code to an internal tree). The APIs will remain exported, so the go-apidiff job will ensure that our Go code defining the APIs is not breaking from a Go perspective.
2. Anything that would cause Kubernetes clients to experience a breaking change when interacting with instances of our CRD via the Kubernetes apiserver.

[joelanford]

To enshrine goal (1) in our codebase, we could implement a test that enforces a specific set of imports. Any future PR that wants to import a new import path would need to also modify our list of allowed import paths in our API.

I would anticipate that that list would start out as k8s.io/apimachinery.

Perhaps https://golangci-lint.run/usage/linters/#depguard would help.

[LalatenduMohanty]

As discussed in the community meeting we are changing this to an issue (from an epic) and will make it part of #1253