Remove assumption that custom resources have a spec field

[khaled]

kubernetes.api.resources options generated as a result of specifying kubernetes.customTypes config values currently assume that the custom types have a spec field.

Though it may be convention, AFAIK it is not a requirement that CRD's have such a field. Here's an example in the wild. And currently there is no clean way to specify different toplevel options such as configuration from the provided example.

FWIW I was able to add additional toplevel options using kubernetes.api.defaults, though this is verbose and probably not its intended use, and as such I consider it an ugly hack :-)

More importantly, AFAICT there is no way to prevent a spec value of {} from showing up in the output, which is invalid if the CRD doesn't have spec in its schema.

[hall]

Looks and sounds right to me; configMap and secret objects don't have a spec field so it's not unreasonable that CRs might not either.