CI/CD workflows

We want to improve automation in all repos for the Kuadrant components. We're aiming for:
1. good coverage of automation tasks related to code style, testing, CD/CD (image builds, releases), etc
2. consistency across components
3. automation as manageable code – i.e. less mouse clicks across scaterred UI "settings" pages and more Gitops, more YAMLs hosted as part of a code base.

As part of a preliminary investigation (https://github.com/Kuadrant/kuadrant-operator/issues/21) of the current state of such automation, the following desired workflows and corresponding status for the Kuadrant controller repo were identified. Please review the list below.

- **A.** Linters & Code style
- [x] **A1.** Built-in auto-format (`go fmt`, `go vet`, `cargo fmt`)
- [x] **A2.** 3rd-party linters ([Reviewdog](https://github.com/reviewdog/reviewdog), [golangci-lint](https://golangci-lint.run/), [Clippy](https://github.com/Manishearth/rust-clippy) - Trailing whitespaces, EOF newline, Language-specific)
- [x] **A3.** Spelling ([client9/misspell](https://github.com/client9/misspell))
- [x] **A4.** Language ([Woke](https://github.com/get-woke/woke))
- **B.** Tests
- [x] **B1.** Unit tests (`go test`, `cargo test`)
- [x] **B2.** End-to-end tests (build an image → deploy → run integration tests)
- [ ] **B3.** Smoke tests (deploy image from [quay.io/kuadrant](https://quay.io/organization/kuadrant) → run integration tests)
- [ ] **B4.** Performance & Benchmarks
- **C.** CI/CD
- [x] **C1.** Build and push image to [quay.io/kuadrant](https://quay.io/organization/kuadrant)¹
- [ ] **C2.** Deploy (shared Kubernetes/OpenShift cluster in the cloud)
- **D.** Release
- [ ] **D1.** Release (tag, version)
- **E.** Code scan (vulnerability, dependency updates)
- [x] **E1.** [Dependabot alerts](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts)
- [ ] **E2.** [Dependabot version updates](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates)
- [x] **E3.** [Dependabot security updates](https://docs.github.com/en/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)
- [x] **E4.** Code vulnerability scan ([CodeQL](https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning), [Red Hat Dependency Analytics](https://marketplace.visualstudio.com/items?itemName=redhat.fabric8-analytics))
- [ ] **E5.** Static Code Analysis ([SonarQube](https://www.sonarqube.org/))
- **F.** Badges
- [x] **F1.** Test status & coverage
- [ ] **F2.** Code analysis (dependencies, security)

¹ Currently configured in Quay instead of GHA.

Workflows do not have to be implemented exactly as in the list. The list is just a driver for the kind of tasks we want to cover. Each component should assess it as it makes sense considering the component's specificities. More details in the original epic: https://github.com/Kuadrant/kuadrant-operator/issues/21.

You may also want to use this issue to reorganize how current workflows are implemented, thus helping us make the whole thing consistent across components.

For an example of how Authorino and Authorino Operator intend to organise this for Golang code bases, see respectively https://github.com/Kuadrant/authorino/issues/351#issuecomment-1234018825 and https://github.com/Kuadrant/authorino-operator/issues/96#issuecomment-1234022236.

Start by reviewing the current automation for the Kuadrant controller repo against the checklist in this issue and the linked preliminary investigation and epic. Define a focused workflow improvement, then verify that the selected automation is consistently represented in the component repositories and covers the agreed task.

Written by the indexing model from the issue text.