Handle version file conflicts during codeflow PR updates

[premun]

Context

In #4196 we implemented basic strategies for conflict resolution of version files during code flows.
The conflict resolution can now correctly resolve conflicts when opening a PR but it probably cannot update the same PR with a new build as the PR contains changed version files.

Goal

When we are flowing an update to an already existing PR branch (so adding a new build to an open PR), we need to make sure version files don't conflict.

• We need to write an E2E VMR test to see what happens to version files. We need to make sure that the test is more close to what happens in the real world - version files are changed in every step and we always flow arcade etc. The current backflow test testing for conflicts in version files is probably not real enough as it does not update version files in forward flows much. In the real world, a backflow always updates the version files which then flow forward and back again. We need to make sure the test does this.
• To solve the conflicts, we might need to cloak the version files (and eng/common) during the backflow updates and just update these files manually based on the build assets after the code flow is done.

[premun]

We have decided that it might be better split the conflict resolution of version files and actual source conflicts so that when there's a conflict with the target branch, the service would only first push commits for the source code changes, the dev would resolve this by merging the target branch and the service would then push the updates to the version files themselves.

The full flow would something like this:

• Flow sources with the version files and eng/common cloaked
• Try merging the branch
  • If it merges, do it and apply version changes on top
  • If it doesn't, stop, drop a comment and wait for human to merge the branches, then apply the version file changes
• If a new update is to be applied to the PR, again flow sources only (because version files would clash anyway for the reasons above).
  • If the PR is waiting for a human to resolve a merge, it can still apply the new sources (this will apply cleanly as it's just a continuation from the source repo)
  • If the merge already happened (regardless of how), it will fix the version files again

And how we will resolve conflicts:

• The eng/common files will be basically treated as now - always overwritten fully as they should match the arcade version.
• The version files will be for now always taken from the repo's branch (target branch in backflows and PR branch in forward flows) and later we will implement the more advanced strategy which will be compiling the content from the information in BAR and in the files themselves.

[premun]

This is now done and a naive strategy to deal with these is deployed in production. A follow-up is opened to improve the algorithm #4342