Possibility to configure backoffLimit in imagepruners.imageregistry.operator.openshift.io

1. Proposed title of this feature request
Possibility to configure backoffLimit in imagepruners.imageregistry.operator.openshift.io

2. What is the nature and description of the request?
Sometimes, the image-pruner job is failing because the OpenShift Container Platform - API is not responding in timely manner or is rather slow. This is mostly happening on large scale OpenShift Container Platform 4 - Cluster and thus rendering the job and therefore the Image-Registry Cluster Operator as degraded. Having the possibility to configure backoffLimit for the job would allow customers to apply slightly more flexibility and allow them to automatically retry the job in case it was failing. Alternative it could also be configured to have backoffLimit set to 3 by default (or some other value). But allowing it to be configured by the customer would allow much more flexibility and help adjust the settings according to the customer environment.

3. Why does the customer need this? (List the business requirements here)
Sometimes the image-pruner may fail, causing the OpenShift Container Platform 4 - Cluster Operator to report degraded state. But when retrying the job shortly after it will run successfully. It thus would be nice to leverage the kubernetes functionality for job object to retry failed jobs automatically by using backoffLimit.

4. List any affected packages or components.
OpenShift Container Platform 4 - Image Registry Cluster Operator