add a versioned CustomResourceExt trait - fixes #497

[clux]

Had a bit of a go at #497, and realised it's not quite that beginner worthy because of one hairy problem:

The new trait needs to hardcode the CustomResourceDefinition type from k8s_openapi if we want to keep enforcing the struct (and we probably should).
Unfortunately, doing this effectively hardcodes the apiextensions version and makes things using #[kube(apiextensions = "v1beta1")] not compile.

So, a couple of options present themselves:

• immediately drop support for v1beta1 (minimally available EKS version supports v1)
• parallel traits that users must select

I think for sake of stability guarantees and #508 parallel traits actually work here:

• #[kube(apiextensions = "v1beta1")] can select the trait and implement the right one
• users can pick out the trait (and it wont compile unless they pick the right one)
• can export them from kube_core under versioned modules
• can still have the "main" (most recent + available) version on the main path

So, if this seems acceptable. I propose this can perhaps serve as a guiding principle for #508

• When we rely on versioned type definitions from kubernetes, we don't remove our old impls until they are removed from major cloud providers (provided we even implemented it in the first place)
• When removing older versions, we mention it in the CHANGELOG

I.e. this case: we can remove kube_core::crd::v1beta1 when kubernetes 1.22 is the minimum EKS/AKS/GKE version.

[lfrancke]

This looks good to me. I wouldn't have thought of the versioning issue at all.
Thank you for tackling this!