Choose the right Konveyor CI build workflow and remove others

There are currently 2 workflows that allow CI to build Konveyor including changes on a component (e.g. for on-PR check).

Initially there was https://github.com/konveyor/ci/blob/main/.github/workflows/global-ci.yml

- builds images locally, upload it to artifact and loads it to minikube tagged as default image for given component, so it is expected it will be used by minikube instead the official one from quay.io
- pros: no dependencies on external services
- cons: I don't think this always work (https://github.com/konveyor/java-analyzer-bundle/pull/179 ?)

Little newer is https://github.com/konveyor/ci/blob/main/.github/workflows/global-ci-bundle.yml
- a build evolution created by @djzager some time back
- builds images, builds konveyor bundle image, push those to ttl.sh and use the bundle image as parameter to Konveyor installation
- pros: reliable and working (from my experience), when debugging, it is obvious what component is custom built and what is default, it is possible use the bundle for deploying the same build locally in minikube (if time-to-live of the image permits)
- cons: dependency on external service (ttl.sh)

Then there is a PR from @shawn-hurley https://github.com/konveyor/ci/pull/149, that might be relevant for this purpose.

We should explore options, discuss, decide and make ideally _one_ fully working, reliable CI buil workflow used across Konveyor components.

Compare .github/workflows/global-ci.yml and .github/workflows/global-ci-bundle.yml, then review konveyor/ci pull request 149. Evaluate the documented build, artifact, minikube, bundle, and ttl.sh behavior and decide which workflow is reliable across Konveyor components. Done means one agreed, fully working CI build workflow remains and the alternatives are removed.

Written by the indexing model from the issue text.