Improvements on the operator tests

[fidencio]

The Operator tests were moved from Jenkins to GitHub action, but the change was done "as it is" (or almost), meaning that we kept the bad things of the Jenkins set-up, and ended up introducing the not optimal things from GitHub actions.

We don't need o build the operator / payloads on every execution of the matrix, as we could easily build it once, store it on ghcr.io, and even help folks debugging things locally to grab that image to use.

Also, we should NOT stop all the executions in case there's one failure, mainly considering the amount of debug information we're providing the users. When the cancellation happens, users are not even aware whether this is a legitimate failure or whether we're in flakiness-land.

[portersrc]

@fidencio, I was looking at the first bit of this (to push operator to ghcr, so we don't always have to rebuild it).

But I see a couple workflows doing this on merge for operator already, except that they're pushing to quay:
https://quay.io/repository/confidential-containers/operator?tab=tags
https://github.com/confidential-containers/operator/actions/runs/7629086331/workflow
https://github.com/confidential-containers/operator/actions/runs/7629086324/workflow

Is it safe to bulldoze the pushes to quay that are happening on merge (so I can push to ghcr), or are those used in many places throughout the project already?

[stevenhorsman]

As discussed on slack, the extra information to note is that the operator image on quay are for things that have already been merged, so are 'stable'. The enhancement suggested here is that when running things that are 'in flight' e.g. PRs, we cache the images in ghcr (or we could pull them from quay if they haven't been updated), but these are the same, or for the same purpose as the quay.io operator images