take advantage of k8s native staetfulset spec instead of defining a custom one in the form of PodOptions in custom_types.go

**Is your feature request related to a problem? Please describe.**
current version of the operator uses a custom type for podspec - https://github.com/bloomberg/solr-operator/blob/master/api/v1beta1/common_types.go#L49. This requires us to update this whenever we would like to add something to the solrcloud pod that is already supported by a k8s pod spec - https://github.com/kubernetes/api/blob/master/core/v1/types.go#L2842

**Describe the solution you'd like**
Use k8s native podspec api for defining the pod spec in solrcloud statefulset podspec - https://github.com/kubernetes/api/blob/master/core/v1/types.go#L2842 should be used instead of https://github.com/bloomberg/solr-operator/blob/master/api/v1beta1/solrcloud_types.go#L102

**Describe alternatives you've considered**
Continue with the current structure and rollout a new version of operator everytime we want to add support for something that is already supported by k8s pod spec but not defined in our custom spec

**Additional context**
and this is applicable for all the other resources not just podspec.

the current spec for solrcloud custom resource looks like this after removing all the comments and stuff

```
type SolrCloudSpec struct {
Replicas *int32
ZookeeperRef *ZookeeperRef
SolrImage *ContainerImage
SolrPod SolrPodPolicy
DataPvcSpec *corev1.PersistentVolumeClaimSpec
BackupRestoreVolume *corev1.VolumeSource
CustomSolrKubeOptions CustomSolrKubeOptions
BusyBoxImage *ContainerImage
SolrJavaMem string
SolrOpts string
SolrLogLevel string
SolrGCTune string
}
```

this is how I think it should be

```
type SolrCloudSpec struct {
Solr StatefuleSetSpec(k8s)
Zookeeper ZookeeperSpec
}

type ZookeeperSpec {
Replicas int
}
```

the above structure is only a rough sketch but that kind of gives the idea. The native k8s `StatefuleSetSpec` will enable the users to use whatever is already supported by k8s native statefulset spec in solrcloud spec.

Read api/v1beta1/common_types.go and api/v1beta1/solrcloud_types.go first, then compare the current custom pod options with the Kubernetes core/v1/types.go pod specification. Trace how SolrCloudSpec is converted into the StatefulSet. Done means the SolrCloud resource uses the native Kubernetes pod specification without losing the operator’s existing options, with the broader resource implications resolved.

Written by the indexing model from the issue text.