Make MSYS2 git compatible (not only Git for Windows)

[zcsizmadia]

---

Description

Checklist

• [x] I have followed the guidelines in the Contributing document
• [x] My changes follow the coding style of this project
• [x] My changes build without any errors or warnings
• [x] My changes have been formatted and linted
• [ ] My changes include any required corresponding changes to the documentation
• [x] My changes have been rebased and squashed to the minimal number (typically 1) of relevant commits
• [ ] My changes have a descriptive commit message with a short title, including a Fixes $XXX - or Closes #XXX - prefix to auto-close the issue that your PR addresses

Fixes #965

Problem: When MSYS2 git is used with Visual Code (instead of Git for Windows), the vscode-gitlens extension fails to initialize:

[2021-09-30 15:37:20:737] c:\Users\USERNAME\.vscode\extensions\eamodio.gitlens-11.6.0\dist\gitlens.js:78:36633
Error: spawn C:\msys64\usr\bin\git.exe ENOENT
[2021-09-30 15:37:20:740] [/c/Project/] Git spawn C:\msys64\usr\bin\git.exe ENOENT • 2 ms 

Issue: MSYS2 git rev-parse --show-toplevel returns cygwin style path vs Git for Windows, which returns Windows style path.

Solution: If Cygwin style path is detected convert it to Windows style

References: https://github.com/microsoft/vscode/pull/134146

[RivenSkaye]

Any progress on this? GH is reporting merge conflicts (but not allowing me to view what conflicts or I'd offer a hand fixing it) and it'd be a very welcome change

[lonelam]

Hi I'm using msys2 recently, this PR is necesary to make gitlens work under msys2, is it possible to merge it or someone who's maintaining could explain why msys2 is not intended to be supported?

[eamodio]

@zcsizmadia Thank you for the PR and really sorry for the LONG delay. This change looks reasonable, and doesn't seem to cause any issues when not using MSYS2 Git in my limited testing (would need to vet it more with subst drives/symlinks, etc). At the same time, I can't really verify if this resolves the issue or MSYS2 Git or not. It feels like it might be the tip of the iceberg -- can others verify that this resolves things?

I'm pretty sure this would also need to get added to rev_parse__git_dir.

So can others test that this won't break things for non-MSYS2 Git users, and also that it will fix things for MSYS2 Git users? If we can get some confidence on that, I will be glad to get this in.

[RivenSkaye]

If someone can give me a couple pointers on getting the forked project to run locally, I'll gladly run it for a testdrive at work next week. Out on vacation now, but after that I can stress test it with pretty much everything for the MSYS2 side of things. If there's any specific stuff that needs to be tested, just throw me a ping and I'll make sure to test that as well

[RivenSkaye]

Update and feedback on this. Not too long ago, ls-files invocations have started suffering issues here as well. Not sure how complete the work is that @zcsizmadia did, but perhaps it'd be best to (pre-emptively) sanitize all command in- and output for git? For the most compatible fix, using Windows paths with forward slashes (C:/path/to/project or ./project) should always work as those are forwarded to the filesystem as-is. If there might still be concerns for things being treated as lists of paths, you could always set MSYS2_ARG_CONV_EXCL="*"