Merge `ApiCapabilities` into `ApiResource`

[clux]

Our ApiResource is intentionally a subset of the upstream APIResource that lets us be able to use the type as a Resource. It has a special meaning as the DynamicType for Resource in the dynamic discovery cases.

ApiCapabilities is more the other part of that; the parts that is not essential to have to use the type with the api, but for helpful for detecting "what you can do with it".

However, the way we have split it is becoming harder to justify:

• Scope is becoming more and more necessary to use the api correctly (more so with Add core_methods directly on Client #1032)
• Picking where to put fields from the upstream APIResource is becoming harder and harder (Add shortnames field in kube::discovery::ApiResource #1002)
• These types are generally constructed together via discovery anyway as (ApiResource, ApiCapabilities)

Thus, I think we should reduce the distance between the native Kubernetes types and do one of the following:

Option 1: Bundle capabilities as an optional field inside ApiResource

A least breaking change type thing.

Option 2: Merge fields from ApiCapabilities as optional fields inside ApiResource

The most breaking potential change. This needs additional breaking changes to flatten the methods on ApiCapabilities into ApiResource.

In both cases:

• discovery goes from returning Vec<(ApiResource, ApiCapabilities)> to Vec<ApiResource>
• ApiResource::erase can set whatever fields we don't need in the runtime to None.

And we would get the struct more in-line with the upstream type, while retaining their light-weight use (optional types does not have an extra memory overhead when they are None) as a DynamicType.

Doing the most breaking change (full merge) I think would be easier because it also helps solve the problem of where to put the upstream fields, and help get direction on things like #1002.

[clux]

Clarifying the argument for it for Scope as it came immediately in #1037.

It's not possible for the new methods to protect against scope misuse on dynamic types as it stands:

impl Client {
    async fn create_namespaced_dyn<K>(&self, ns: &Namespace, pp: &PostParams, data: &K, dt: &K::DynamicType) -> Result<K>
    where:
        K: Resource<Scope = DynamicResourceScope> + Serialize + DeserializeOwned + Clone + Debug,
    {
        // TODO: need to runtime limit function based on the dynamic Scope of the dynamic resource
    }

Because of the dynamic type, scope needs to be limited at runtime rather than by a type constraint. This currently cannot be done because the Scope resides on ApiCapabilities but we really need it inside the DynamicType (which is ApiResource).