Split Kubernetes Model into smaller jars corresponding to each apiGroup

[rohanKanojia]

Right now our model has lots of classes and if we add Sundrio helper classes too they become a lot. @iocanel checked out number of classes generated and these were his findings:

It contains:
- 38 Resource definitions for Kuberntes 
- 20 Resource definitions for Openshift

These objects include properties of around 578 different types.
We do generate 3 classes for each to satisfy the builder needs (Fluent, FluentImpl & Builder).

Which takes us close to 2312 classes.

To support nesting in builder we also use nested classes (should be 2 nested classes per `buildable` property). In total there should be around 5000 of those.

The remaining 2000 classes, could possibly be considered part of optional features, and these are the only classes we could possibly get rid of (by restricting the model DSL).

But we don't always need all the classes in most of the cases. This seems to be creating problems in Quarkus Kubernetes Client Extension where the build is taking too much time on JDK11.

As per discussions in Quarkus channel, we should probably split kubernetes model into several modules each specific to an apiVersion in Kubernetes. So in the end kubernetes-model would consist of several small modules like this:

  <modules>
       <module>kubernetes-model-openshift</module>
       <module>kubernetes-model-admission-v1beta1</module>
       <module>kubernetes-model-apps-v1</module>
       <module>kubernetes-model-batch-v1</module>
       <module>kubernetes-model-networking-v1</module>
       <module>kubernetes-model-storage-v1</module>
       <module>kubernetes-model-storage-v1beta1</module>
       <module>kubernetes-model-apimachinery-meta-v1</module>
       <module>kubernetes-model-networking-v1</module>
       <module>kubernetes-model-autoscaling-v1</module>
       
       ...
  </modules>