Issue title: Admission blocks integers in CPU and memory resources
 Issue body: <!-- This form is for bug reports and feature requests ONLY!
Also make sure that you visit our User Guide at https://kubevirt.io/user-guide/
-->

**Is this a BUG REPORT or FEATURE REQUEST?**:

/kind bug

**What happened**:

The validation of VM yaml now blocks integers. This isn't a huge issue but it is making users need to go "fix" yaml and it behaves differently from other resources.

The OpenAPIv3 schema for the VirtualMachine and VirtualMachineInstance CRDs seem to allow integers or strings per standard Kubernetes APIs. Yet kubevirt validation doesn't behave like other Kubernetes resources (e.g. deployments, pods) and allow/interpolate integers, e.g.:

```
spec:
  domain:
    resources:
      requests:
        cpu: 1
      limits:
        cpu: 1
```

kubevirt *requires*:

```
spec:
  domain:
    resources:
      requests:
        cpu: "1"
      limits:
        cpu: "1"
```

I see the CRD spec looks proper:

```
                 resources:
                    description: Resources describes the Compute Resources required
                      by this vmi.
                    properties:
                      limits:
                        additionalProperties:
                          anyOf:
                          - type: integer
                          - type: string
                          pattern: ^(\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$
                          x-kubernetes-int-or-string: true
```

Mutating webhook is called:

```
{"component":"virt-api","level":"warning","msg":"vm-mutator: received invalid object in request","pos":"vm-mutator.go:52","timestamp":"2021-01-14T19:28:59.235853Z"}
{"component":"virt-api","level":"info","msg":"rejected vmi admission","pos":"webhooks.go:52","timestamp":"2021-01-14T19:28:59.239442Z"}
```

I've traced this through the code a bit but I don't ultimately see anything unexpected, I see we compose the API definitions from the kubernetes schema based on CRD naming and and load the standard openapi builder libs. I see we have some additional validation we are adding but I haven't pinpointed the cause yet. Hoping someone with deeper understanding would be able to find it easier.

**What you expected to happen**:

**How to reproduce it (as minimally and precisely as possible)**:
Tested against v0.36.0, v0.35.0, v0.32.0, v0.30.0. Last known version that did not do this was v0.29.0, but will continue testing to find where change occurred.

Try to create a VM with resources like:

```
spec:
  domain:
    resources:
      requests:
        cpu: 1
      limits:
        cpu: 1
```

**Anything else we need to know?**:

**Environment**:
standard 'make cluster-up' with version 0.35.0 and version 0.36.0 deployed via operator. Kubernetes 1.18.3

 Comments: 
 Comment 0: I think the issue might be fixed by `https://github.com/kubernetes/kube-openapi/pull/221` and also the issue is probably in this dependency. We need to check if we updated this dependency recently. @mlsorensen thanks for the last known version where it works!
 Comment 1: Cool, thanks for pointing that out.  I was going to see if I could test that out quickly but it seems it may be a bit tricky to upgrade the version of this module given changes in dependent/related modules, I can get past some of it by upgrading openshift/kubernetes modules to v0.19 but it looks like that has its own issue missing "auditregistration/v1alpha1"...
{'source': 'GithubIssues', 'repo_name_with_owner': 'kubevirt/kubevirt', 'issue_id': 786396613, 'repo_stars': 3603.0}