Automate backports

[carlosthe19916]

The main branch will continue to evolve while the branch release/0.2.z will serve the future downstream releases.

We need to set up basic automation for backporting changes between branches. Starting with something basic like https://github.com/korthout/backport-action would give us some benefits

[gildub]

@carlosthe19916, being able to have PRs automatically backported using tags sounds good.
What we need to assess is if there are any risks of code automatically backported by "accident".
I suppose that goes along with how we monitor the process/results including when it fails.

[carlosthe19916]

What I have in mind is:

• Developer opens PR-X. If he wants to backport that PR once it is merged then he manually adds a label to the PR backport to release/0.2.z. So this is an intentional and manual thing.
• Once the PR-X is merged then GH actions create a backport PR against release/0.2.z. This PR goes all the normal test process and eventually manually merged by someone

This process is a mainstream process IMHO.

This is a concrete example of a backport being done with automation konveyor/tackle2-ui#2083.

• PR ✨ Update stakeholders table to use ActionsColumn konveyor/tackle2-ui#1923 was labeled with cherry-pick/release-0.5
• The the automation comes and creates a backport here ✨ Update stakeholders table to use ActionsColumn (#1923) konveyor/tackle2-ui#2083

I don't see the risk of any accident to be honest.

[carlosthe19916]

@gildub I created a PR that should cover this issue #341 . Please review it.