Add reusable end-to-end deploy workflows (dev/staging/prod)

[Christdej]

Summary

Adds three reusable workflows that compose the existing armada building blocks (build_and_publish_docker_image_to_container_registry.yml + update_kubernetes_deployment.yml) into full deploy pipelines for services deploying via kustomize to an equinor infrastructure repository.

• deploy_to_development.yml – on push to main: publish dev.<short-sha> tag and update the development kustomize overlay.
• deploy_to_staging.yml – on release publish: publish <tag> + :latest and update the staging overlay.
• promote_to_production.yml – manual dispatch: read the tag currently deployed to staging from the infrastructure repo, copy that image (docker buildx imagetools create) from staging to production registry (both :tag and :latest), and update the production overlay.

Motivation

Service repositories re-implement this orchestration today. Each of the eight sara-* repos contains near-identical copies of deploy_to_development.yml, deploy_to_staging.yml, promote_to_production.yaml, and (for some) a local publish_component.yml duplicating armada's build_and_publish_docker_image_to_container_registry.yml. That's a lot of duplicated YAML, and any change to the pipeline (registry rename, new step, new metadata) has to fan out to N repos.

After this PR, a consumer's dev deploy becomes:

```yaml
jobs:
deploy:
uses: equinor/armada/.github/workflows/deploy_to_development.yml@main
with:
registry: roboticsdevacr.azurecr.io
image_name: robotics/sara-anonymizer
infrastructure_repository: equinor/analytics-infrastructure
secrets:
registry_username: ${{ secrets.ROBOTICS_ROBOTICSDEVACR_USERNAME }}
registry_password: ${{ secrets.ROBOTICS_ROBOTICSDEVACR_PASSWORD }}
deploy_key: ${{ secrets.ANALYTICS_INFRASTRUCTURE_DEPLOY_KEY }}
```

Companion PRs against the sara-* repos will adopt these workflows.

Behavior

Matches the current sara pattern (post recent consolidation to a single `roboticsdevacr/roboticsstagingacr/roboticsprodacr` registry per environment):

• Dev: publishes only `dev.` (no `:latest`).
• Staging: publishes `:` + `:latest`.
• Production: copies staging image to prod registry as `:tag` + `:latest`.

Production tag lookup uses `grep newName: /` to find the image block, matching how `update_kubernetes_deployment.yml` already resolves the image line (safer than the current per-repo `cut -d: -f2` approach that assumes a single reference to the substring in the file).

Notes

• Internal composition uses relative `uses: ./.github/workflows/...` so all three reusables resolve against the same armada ref the consumer pinned.
• Consumers should pin `@main` for now; consider tagging (`@v1`) once we have a rollout window.
• Scope is currently single-image services. Multi-image / matrix consumers (flotilla, sara, isar-*) can be added later.