Create permanent `pr-deploy` branch

[c-pius]

Description

:exclamation: FIRST verify with SRE that the concept below can be achieved.

Create a permanent pr-deploy branch and PR in management-plane-charts repository. Every time we merge a commit on lifecycle-manager:main, we want the branch/PR to be updated automatically with the new commit hash so that the changes are deployed continuously for testing.

Acceptance Criteria

• [ ] clarified with SRE if the last deployment from this PR can be sticky or at what frequency it will be overwritten by a sticky deployment (i.e., latest semver release)
• [ ] branch / PR created targeting charts/lifecycle-manager branch
  • reasonable name chosen
  • do not merge label added
  • pr-deploy label added
• [ ] branch / PR is automatically updated with changes from lifecycle-manager:main
  • found out how to sync the changes automatically (e.g., via a webhook triggered on commits on lifecycle-manager:main)
  • found out how to get the needed image tags
  • found out how to bump the chart version automatically (always needs to be higher than the latest chart version on charts/lifecycle-manager)

Reason

We want to have our changes to lifecacle-manager:main continuously deployed to DEV for testing

[jeremyharisch]

I have clarified with the SREs with the following output:

• The image, from a PR in management-plane-charts will be deployed until a new version arrives. That could be another pr-dev, or a normal version bump
• Deployed pre-releases are not subject to promotion, allowing for testing and refining changes.
• To trigger this functionality, add the pr-deploy label to the pull request in the management-plane-charts repository.
• Once labeled, each commit to the chart will be packaged with a pre-release tag and deployed to kcp-dev.
• Deployed pre-releases are not locked, allowing other deployments to override them.
• Upon merging the pull request, the final release will override the pre-release version.
• Argopromote version 1.4.0 includes a reset subcommand to revert to the last successfully deployed version.

[c-pius]

Deprioritized this as it is not a current pain point. We can look at it later again if we find that automatic deployments to DEV ease our dev process.