[RFE] Make CI and Release tooling more declarative

[djzager]

There are some problems that we currently run into with our Github Actions based CI/CD release tooling:

1. Some workflows like image building, issue reconciling, cherry picking have to exist all repositories. This creates a burden when new repositories are added under the Konveyor umbrella or when one of those workflows needs to be modified.
2. Not all repositories produce container images as their release artifact. Instead they are git cloned into other container images.
3. It's very easy for container images to become out of sync. A concrete example is that the analyzer-lsp container image needs jdtls-server-base. Changes to jdtl-server-base SHOULD cause analyzer-lsp to be rebuilt.
4. https://github.com/konveyor/operator/blob/main/.github/workflows/create-release.yml relies on waiting for images to exist which causes problems when a release pipeline publishes more than 1 image.
5. Cleaning up failed repo releases + tags + container images is manual process

The aim of this work would be to improve the CI and Release Tooling, provide a single source of truth, and push CI/CD release tooling updates to our project repositories more automated.

Tasklist based on the enhancement described in #201.

### Tasks
- [ ] Update config.yaml in release tools to reflect dependency relationships between components of Konveyor. This will require an update to the config types.
- [ ] Generate release pipeline from config.yaml. When this work is complete the release pipeline for main, and releases going forward, will be in the release-tools repository.
- [ ] Move every Konveyor repositories CI checks to use `konveyor/ci/.github/workflows/global-ci-bundle.yml`. Should seriously consider automation to enforce this on all konveyor repositories (ie. every component should have PR checks to make sure the PR doesn't break CI).
- [ ] Need a reusable action or step on CI failure for nightlies that takes all of the images from a run, mirrors them to quay + tags and pins them by SHA + collects them into a bundle and informs the failure notification how an engineer could recreate the failed build.
- [ ] ...

[shawn-hurley]

I would love for this to include some way of standardizing on the bundle CI and removing the other CI

[jmle]

I think some of these have already been implemented, for instance the example of point (3). @shawn-hurley @djzager @eemcmullan I wonder what's remaining?