Add workflows for Building and Deploying Docker Images

[FinnIckler]

In Preparation for #8314 I added two new workflows.
On Release:

• Builds new Images and marks them as latest for staging and prod
• Pushing an image triggers the deployment pipeline for prod
• Sidekiq image is updated and deployed
• Staging image is updated and deployed

On PR Comment:

• Allows deploying PRs to staging by writing '@thewca-bot deploy staging'
• Replaces Main and Sidekiq Staging images if triggered

We could think of another way of deploying staging images, but I think this could work well. This almost makes the deploy repository redundant, depending on if we want to add a separate workflow for updating documents.

[gregorbg]

This almost makes the deploy repository redundant, depending on if we want to add a separate workflow for updating documents.

I think the documents repository is self-sufficient and they don't manage their deployments over thewca/deploy. But obviously they still need to maintain a way to update their documents independent of the main code, so you probably need a PR over there to adjust the commands to the new infrastructure.

Then the only remaining GH Workflow in the deploy repository is the one for Regulations. WRC definitely needs it, and the reasons why it lives in the deploy repository are:

1. It already had a lot of Secrets installed so it was more convenient to configure there, rather than moving it to the regulations repository.
2. We were not sure whether having a workflow that can be manually triggered in a public repository could be dangerous. External people defintely don't have permission to trigger workflows, but (I think) they do have permissions to view workflow logs. Could that be problematic in any way if we moved the Regulations workflow to the (public!) Regulations repository?