Goal: Allow the SDK to rely on Kubebuilder for scaffolding of Golang-Operator projects.

Benefit hypothesis: Save engineering cycles and get more upstream buy-in by collaborating on a single upstream solution to scaffold Golang-Operator code.

Why is this important: Currently the SDK maintains its own Golang project structure and code scaffolds. Though relying on controller-runtime like Kubebuilder thus it's different enough to require users to choose upfront between Kubebuilder-style and Operator-SDK-style projects and requiring a separate engineering group to maintain. Integrating and extending Kubebuilder instead of duplicating the effort will increase our upstream presence in projects that the SDK relies on and allow users to use the SDK with existing Kubebuilder projects to add the additional SDK capabilities (packaging, testing, OLM integration) on top.

Acceptance criteria:

• SDK users can create Golang-Operator projects using the same CLI switches and on-disk structures that Kubebuilder projects have
• SDK users can re-use existing Kubebuilder projects
• SDK engineering can rely on Kubebuilder being integrated instead of writing custom scaffolding logic for Golang-Operators, thus freeing up engineering cycles long-term