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 Authorino Operator repo were identified. Please review the list below.

- **A.** Linters & Code style
- [x] **A1.** Built-in auto-format (`go fmt`, `go vet`, `cargo fmt`)
- [ ] **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)
- [ ] **A3.** Spelling ([client9/misspell](https://github.com/client9/misspell))
- [ ] **A4.** Language ([Woke](https://github.com/get-woke/woke))
- **B.** Tests
- [x] **B1.** Unit tests (`go test`, `cargo test`)
- [ ] **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)
- [ ] **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)
- [ ] **E3.** [Dependabot security updates](https://docs.github.com/en/github/managing-security-vulnerabilities/configuring-dependabot-security-updates)
- [ ] **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
- [ ] **F1.** Test status & coverage
- [ ] **F2.** Code analysis (dependencies, security)

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 intends to organise this for a Golang code base, see https://github.com/Kuadrant/authorino/issues/351.

Start by reviewing the current automation in the Authorino Operator repository, then read the linked preliminary investigation and the Authorino example issue. Compare existing workflows with the A–F checklist and define a manageable, consistent scope for this component. Done means the selected automation areas are implemented or explicitly assessed with repository-hosted configuration.

Written by the indexing model from the issue text.