Track source mutations that occur before build

[dagood]

We use patches for some changes, but for others, we have MSBuild targets that mutate source code directly. This is useful for routine changes, where a patch would be frequently invalidated but a find-replace type of operation is reliable. For example, editing NuGet.configs and global.jsons.

Right now, since darc clone disconnects each repo's working tree from Git, it's hard to determine what the modifications are. We should track them to make it more obvious what's being built. It would probably be sufficient to generate a patch file against the cloned commit, just before the primary build command runs.

---

Mutations are significantly more resilient than patches for servicing updates, but the downside is it's harder to tell what's going on. By tracking the changes, it might be reasonable to migrate some non-integrable 3.1 patches into mutations to make it easier to get updates out quickly.

Just like patches, mutations are also something we should aim to minimize, to have a sensible build. But it may not be reasonable to eliminate mutation in some cases, such as hard-coded feeds in NuGet.configs that don't allow anonymous access.

[MichaelSimons]

As part of the Unified Build project, source-edits will be supported and will automatically flow back to the product repos. Source mutations done as part of the build present a UX problem as they pollute the workspace. #3664 tracks the work to eliminate all source mutations.