Refine tooling and the developer experience around VMR code flow

## Context

The outcome of the previous work (https://github.com/dotnet/arcade-services/issues/2995) will be a crude E2E experience which will provide the necessary functionality to flow code to/from the VMR. However, we need to make sure that once the whole .NET organizations switches onto this new code flow, the experience is refined so that the .NET team stays productive.

## Goals

Make sure that the experience around following code flow areas is great.

### Conflict identification and resolution

When conflicts happen, devs need to be able to quickly identify conflicting commits (VMR vs original repo) so that they can make an educated decision to resolve these. As an example, this means that the code flow PRs contain sufficient information (e.g. links to diffs, comments by the Maestro bot when conflicts occur etc.).
Furthermore, we need to make sure that conflicts do not occur in metadata files (like version files or VMR source manifest etc). In case they do, we should provide tooling to help devs resolve these conflicts while not corrupting the metadata in a way that would block the code flow.

### Tooling & documentation investment

The tooling used by devs (`darc`) needs to contain functionality that will help devs with the code flow. As an example, devs need to be able to effectively locally transfer changes between the VMR, it is easy to determine the state of the flow and find where commits are...
The tooling must be sufficiently documented so that working with the system is as self-service as possible.

### Community policies

We need to make sure that we have a story and rules for making sure the code flows. This means making sure that the code is reviewed sufficiently and by the right people. We need to figure out a system of notifications so that:
- It is clear what the current policy is - e.g. VMR is not open to PRs yet, or it is but it should be used for some limited set of changes, or maybe we only use the VMR in servicing etc.
- PRs in the VMR are routed to the right owners.
- PRs made by automation do not cause noise (e.g. do not require original reviewers/code owners from the original repository to review again).