[wip] move to dynamic provisioning through crd

[OliverMKing]

Description

Adds the CRD for dynamic provisioning and kubebuilder boilerplate

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

How Has This Been Tested?

Tested all gen code and generated crd is correct. That's all this PR does for now.

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes
• [x] Any dependent changes have been merged and published in downstream modules

[coveralls]

Pull Request Test Coverage Report for Build 6355970282

• 8 of 10 (80.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.05%) to 88.669%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/controller/controller.go	8	10	80.0%
<!--	Total:	8	10	80.0%	-->

Totals
Change from base Build 6331531917:	-0.05%
Covered Lines:	1972
Relevant Lines:	2224

---

💛 - Coveralls

[OliverMKing]

// ObjectReference contains enough information to let you inspect or modify the referred object. // --- // New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs. // 1. Ignored fields. It includes many fields which are not generally honored. For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage. // 2. Invalid usage help. It is impossible to add specific help for individual usage. In most embedded usages, there are particular // restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted". // Those cannot be well described when embedded. // 3. Inconsistent validation. Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen. // 4. The fields are both imprecise and overly precise. Kind is not a precise mapping to a URL. This can produce ambiguity // during interpretation and require a REST mapping. In most cases, the dependency is on the group,resource tuple // and the version of the actual struct is irrelevant. // 5. We cannot easily change it. Because this type is embedded in many locations, updates to this type // will affect numerous schemas. Don't make new APIs embed an underspecified API type they do not control. // // Instead of using this type, create a locally provided and used type that is well-focused on your reference. // For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .

Probably need to switch from the ObjectReference type