Generic Custom Resource Definition support

[KnVerey]

Instead of hardcoding details about what Shopify's TPR controllers are expected to create, we should provide generic support based on a conventional status field. According to @wfarr investigation, such a status field will be easier to implement in the new CustomResourceDefinitions.

• We'd query the cluster for valid CRD types at the beginning of the deploy, before creating resource instances.
• CRD instances would be expected to expose status fields from which we can derive their success/failure
  • We should have a convention for this that lines up with the fields/values first-party controllers set
  • We can provide an override mechanism, likely an annotation, for specifying custom fields/values

[wfarr]

I need to dig more in practice, but my belief on looking at these particular bits of code lead me to believe that CRDs offer a true status sub-resource that can be called directly, avoiding some of the pains of circular updates:

• https://github.com/kubernetes/kubernetes/blob/04477ff90ceb55b864a4ac96fcc8c8b510414ead/staging/src/k8s.io/apiextensions-apiserver/pkg/apiserver/apiserver.go#L125-L133
• https://github.com/kubernetes/kubernetes/blob/04477ff90ceb55b864a4ac96fcc8c8b510414ead/staging/src/k8s.io/apiextensions-apiserver/pkg/registry/customresourcedefinition/etcd.go#L150-L173
• https://github.com/kubernetes/apiextensions-apiserver/blob/master/examples/client-go/main.go#L78-L91
• https://github.com/kubernetes/apiextensions-apiserver/blob/master/examples/client-go/apis/cr/v1/types.go
• https://github.com/kubernetes/apiextensions-apiserver/blob/master/examples/client-go/client/cr.go#L97-L99
• https://github.com/kubernetes/apiextensions-apiserver/blob/master/examples/client-go/controller/controller.go#L96-L113