Enable s390x CI testing and define required pull jobs

[c-monaa]

Summary
As part of the proposal to enable s390x architecture builds for hostpath-provisioner-operator, it would also be useful to discuss what CI test coverage should be enabled for this architecture.
Before enabling tests, it would be good to get feedback on which CI jobs should run on s390x and what level of testing makes sense initially.

Context
The project currently runs CI jobs for testing and image publishing. This includes a presubmit unit test job and postsubmit jobs that build and publish container images.
Configured CI jobs for this repository: https://prow.ci.kubevirt.io/configured-jobs/kubevirt/hostpath-provisioner-operator

From what I can see, the only existing pull-* presubmit job for this repository is: pull-hostpath-provisioner-operator-unit-test
If we add s390x support to builds, the next step would be to decide how much CI coverage we want for this architecture.
As a starting point, it seems reasonable to run the existing unit tests on s390x since they should be architecture-independent and relatively low-cost to execute.

Feedback
It would be great to get input from maintainers and the community

[awels]

For the operator we only run unit tests. This is a pretty basic operator, and we actually use the operator to deploy in the hostpath-provisioner repo. So any functional testing of the operator happens there. I am not aware of any assumptions that would prevent running the unit tests on s390x. We can definitely add a new s390x unit test lane similar to what happens in kubevirt/kubevirt or kubevirt/containerized-data-importer.