Description of problem:

bundle images are usually non-manifest-list images that report support only for amd64, e.g., https://catalog.redhat.com/software/containers/openshift4/ose-cluster-nfd-operator-bundle/5f5ba417bed8bd77416201ed.

When an operator is installed via operator-sdk run bundle with such an image, if the MTO is operating, the extraction pod will be forced to land on amd64, even if the other containers use multi-arch images.

This is an edge case where the container uses a single-arch image but the entrypoint is a valid binary, as coming from another source. In the olm case, the binary is extracted by an initContainer using a proper multi-arch image and stored in volume. The volume is mounted in the container with the single-arch image and the entrypoint for that container is the binary in that volume.

Possible solutions are:
1. when computing the compatible architecture set by looping through the container images, if an image is found to be non-manifest-list, and the entrypoint of the container is set in a volume, ignore the reported architecture and continue with the others.
2. Look at the OLM bundle labels in the image. If it reports it's a bundle, ignore it when computing the supported architectures

(1) tries to generalize, (2) is strictly related to OLM bundles.

If we don't address this case and the operator executes on a cluster with no amd64 workers, the deployment of operators may fail.