Improve Backstage CRD to simplify k8s runtime customization

[gazarenkov]

We have very flexible layered mechanism of Backstage runtime configuration:

• Operator default config
• CustomResource raw config
• CR configuration

Raw config is powerful but not always convenient to use as required rewriting the whole resource, which in most of the cases is quite big Backstage Deployment.yaml.
So, to simplify a way to configure some parts of configuration and reach “features parity” with Helm Chart (following user’s feedback) we need to extend CR configuration

For the time being we clearly need to have options (at least) for:

• Pod.spec.container.resources configuration
• Pod.spec.container(side cars, wee also [Proposal] More user-friendly Sidecar containers support #276 )
• Pod.spec.volumes (side cars)
• Pod.objectmeta.labels and annotations

[gazarenkov]

As documented in #388

This PR includes new way to configure Backstage deployment, now (in contrary to raw config) it is possible to add the changes as a and valid "fragment" of appsv1.deployment object inside Backstage CR and those fields will be merged with default (+raw) configuration, like:

apiVersion: rhdh.redhat.com/v1alpha2
kind: Backstage
metadata:
  name: my-backstage
spec:
  deployment:
    spec:
      template:
        metadata:
           labels:
              label1: value1
        spec:
          containers:
            - name: backstage-backend
               resources:
                  requests:
                      cpu: 250m
                      memory: 256Mi
           - name: my-sidecar
              image: my-sidecar
          volumes:
            - ephemeral:
                volumeClaimTemplate:
                  spec:
                    storageClassName: "my-special-class"
              name: dynamic-plugins-root

Also, since this addition causes changes in the API, new API version v1alpha2 was added. So, as for Operator versions 0.3.x and 0.4.x (if we consider 3 months release cadency and 6 months API maintain) it will support as minimum both v1alpha1 and v1alpha2 (which become a storage version). After upgrading Operator to 0.3.x the following behaviour expected:

• existed v1alpha1 CRs are working and shown as v1alpha2
• both v1alpha1 and v1alpha2 CRs can be added/updated, all shown as v1alpha2

NOTE: v1alpha2 is backward compatible with v1alpha1 w/o data conversion

Openshift NOTE: deployment.patch field won't show up in the "Form view" when creating a CR from the OCP Web. To be able to edit it with ODC use "YAML view".