use Git 2.7 config extensions to fast-fail when using incorrect Git binary

I wanted to capture here a suggestion from @bk2204, one of the Git developers, regarding how we could use Git config extensions to prevent data corruption or other errors if a user accidentally runs a non-VFSForGit-enabled version of Git within a VFSForGit repository. In his words:

Git 2.7.0 and newer have support for an extensions section in the config. If you set core.repositoryFormatVersion to 1, then you can set extensions, and if the git binary in question doesn’t understand them, it will abort. Therefore, for VFSForGit repositories, it’s possible to simply create your own extension, say, extensions.vfsforgit, and set it to 1 in the repository config file. A suitably enabled Git will know about it, but if there’s a different Git on the system that isn’t capable of that, it will fail in a noisy way, making it obvious what’s going on. libgit2 should also fail here, which we’d want as well.

That doesn’t solve the problem of finding the right Git, but it does ensure that if we use PATH, we don’t have to worry as much that we accidentally have the wrong Git. We won’t, for example, have to worry about data corruption.

Currently the TrySetRequiredGitConfigSettings() method sets core.repositoryFormatVersion to 0, but perhaps this could be changed in a future VFSForGit upgrade that also added a custom extension like extensions.vfsforgit to pre-existing (and new) repository config files, and which was coordinated with a change to the VFSForGit-enabled Git binary so that it expects to find that custom extension.

Start in GVFS/GVFS/CommandLine/GVFSVerb.cs at TrySetRequiredGitConfigSettings(), where the repository format version is configured. Review how VFSForGit-enabled Git handles repository extensions and coordinate the expected configuration with the Microsoft/git binary. Done means unsupported Git binaries fail noisily while compatible VFSForGit repositories continue to work.