Kubernetes content is specific to OpenShift

#### Description of problem:

OpenShift was the first kubernetes distribution with content in this repository. As a result, many of the rules and rule groups in `applications/openshift` are OpenShift-specific.

Now that we are adding content for other distributions, we should find a way to organize the content so it's platform agnostic. This
makes it easier to use the content for EKS, ASK, OpenShift, and vanilla kubernetes.

Ideally, it would be great to:

1.) Reuse as many existing rules as we can
2.) Have content to be specific to the benchmark in question (content shouldn’t bleed details about irrelevant distributions when in use)
3.) Easily navigate content

#### Potential solutions:

##### Group rules by distribution

The layout would adhere to the following convention, where groups could be nested as needed:

```applications/kubernetes/{distribution}/{group}/{rule}```

Examples of the directory structure, omitting rules and only focusing on layout:

```applications/kubernetes/``` - contains all common rules for kubernetes
```applications/kubernetes/eks/``` - contains rules specific to EKS
```applications/kubernetes/aks/```- contains rules specific to AKS
```applications/kubernetes/openshift/``` - contains rules specific to OpenShift
```applications/kubernetes/eks/logging/``` - contains rules specific to EKS logging
```applications/kubernetes/openshift/logging/``` - contains rules specific to OpenShift logging

Benefits

- Well organized
- Easy to find rules that are specific to a distribution
- Easy to reuse common rules that are generally applicable to kubernetes

Drawbacks

- Requires a lot of refactoring to get there
- Having two groups with the same name and product type [breaks](https://github.com/ComplianceAsCode/content/issues/8190) CaC content builds
- Example: we can’t do applications/kubernetes/eks/logging and applications/kubernetes/openshift/logging
- We would need to be careful nesting groups under the distribution and it would be inconsistent to have some logging rules in ```logging/``` for one distribution and not another

##### Group rules by component subsystem

The layout would adhere to the following convention:

```applications/kubernetes/{group}/{distribution}/{rule}```

Examples of the directory structure, omitting rules and only focusing on layout:

```applications/kubernetes/``` - contains all common rules for kubernetes
```applications/kubernetes/logging/``` - contains rules specific to logging
```applications/kubernetes/worker/``` - contains rules specific to worker nodes
```applications/kubernetes/logging/eks/``` - contains rules specific to EKS logging
```applications/kubernetes/logging/openshift/``` - contains rules specific to OpenShift logging
```applications/kubernetes/worker/openshift/``` - contains rules specific to OpenShift workers

Benefits

- Uses a similar convention to what exists in ```linux_os```
- Still relatively easy to find rules, especially by subsystem
- Common rules can still be towards the top of the hierarchy

Drawbacks

- Having two groups with the same name and product type [breaks](https://github.com/ComplianceAsCode/content/issues/8190) CaC content builds
- Can’t do applications/kubernetes/logging/eks and applications/kubernetes/worker/eks

##### Parameterize rules
The layout would adhere to the following convention, where groups are optional:

```applications/kubernetes/{group}/{rule}```

Examples of the directory structure, omitting rules and only focusing on layout:

```applications/kubernetes/``` - contains all common rules for kubernetes
```applications/kubernetes/logging/``` - contains rules specific to logging
```applications/kubernetes/worker/``` - contains rules specific to worker nodes

Benefits

- Probably the closest to what we have today if we substitute ```openshift``` for ```kubernetes``` in the application path
- We don’t have issues with conflicting group names because we omit the distribution from the path entirely
- We don’t have issues with conflicting group names because we won’t nest subsystems under distributions

Drawbacks

- We’re going to be doing a lot of jinja templating logic and rules could get complex