docs/README: Useless bump to get a new commit hash

The MCO has a bug where it relies on its commit hash to mark the
target version of rendered MachineConfigs [1].  We didn't get a bump,
or even a rebuild between 4.7.11 and 4.7.12:

  $ oc adm release info --commits quay.io/openshift-release-dev/ocp-release:4.7.11-x86_64 | grep machine-config-operator
    machine-config-operator                        https://github.com/openshift/machine-config-operator                        e3863b0
  $ oc adm release info --commits quay.io/openshift-release-dev/ocp-release:4.7.12-x86_64 | grep machine-config-operator
    machine-config-operator                        https://github.com/openshift/machine-config-operator                        e3863b0

So the MCO starts updating the pools between the two releases and
immediately says "ahh, looks like I've already finished updating",
when it hasn't.  Lots of example jobs linked from [2], including [3]:

  the "master" pool should be updated before the CVO reports available at the new version

From that job:

  $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/logs/release-openshift-origin-installer-e2e-aws-upgrade/1395451649530531840/build-log.txt | grep 'clusteroperator/machine-config.*version'
  INFO[2021-05-20T20:59:59Z] May 20 20:39:58.483 I /machine-config reason/OperatorVersionChanged clusteroperator/machine-config-operator started a version change from [{operator 4.7.11}] to [{operator 4.7.12}]
  INFO[2021-05-20T20:59:59Z] May 20 20:40:04.662 I /machine-config reason/OperatorVersionChanged clusteroperator/machine-config-operator version changed from [{operator 4.7.11}] to [{operator 4.7.12}]
  INFO[2021-05-20T20:59:59Z] May 20 20:40:04.815 I clusteroperator/machine-config versions: operator 4.7.11 -> 4.7.12
  INFO[2021-05-20T20:59:59Z] May 20 20:40:05.420 W clusteroperator/machine-config changed Progressing to False: Cluster version is 4.7.12

The machine-config operator didn't actually roll all the control-plane
nodes in six seconds.

The useless docs bump will give us a new commit hash, so the MCO will
understand that a 4.7.11 -> 4.7.13 bump is a real update that takes
some time to roll out.  Once we get [1] fixed, we won't need hacks
like this for future releases.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1955929#c1
[2]: https://amd64.ocp.releases.ci.openshift.org/releasestream/4-stable/release/4.7.12#upgrades-from
[3]: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-e2e-aws-upgrade/1395451649530531840

docs/README.md

@@ -4,8 +4,8 @@ OpenShift 4 is an [operator-focused platform](https://blog.openshift.com/openshi
 and the Machine Config operator extends that to the operating system itself,
 managing updates and configuration changes to essentially everything between the kernel and kubelet.
 
-To repeat for emphasis, this operator manages updates to systemd, cri-o/kubelet, kernel, NetworkManager,
-etc.  It also offers a new `MachineConfig` CRD that can write configuration files onto the host.
+To repeat for emphasis, this operator manages updates to systemd, cri-o/kubelet, kernel, NetworkManager, etc.
+It also offers a new `MachineConfig` CRD that can write configuration files onto the host.
 
 The approach here is a "fusion" of code from the original CoreOS
 Tectonic as well as some components of Red Hat Enterprise Linux Atomic Host,