MinGW-w64 / MSYS2 support

[HertzDevil]

As part of crystal-lang/crystal#6170, it makes sense to test Shards on MSYS2 and package Shards for it as well. The bad news is that all the resolvers are problematic on MSYS2:

• Mercurial is only available from the MSYS environment, and installs /usr/bin/hg, a Python script with a shebang, which Process.run doesn't handle. Nor is running the script with Python expected on Windows, since Mercurial packages hg.exe using PyOxidizer; the specs will pass if this executable is exposed inside MSYS2 with something like PATH="$(cygpath $PROGRAMFILES)/Mercurial:$PATH".
• Fossil has a UCRT64 build but it is completely broken. It is a single executable, so downloading the official Windows build somewhere to $PATH would work. (If obtained via WinGet, it should be available at $(cygpath $LOCALAPPDATA)/Microsoft/WinGet/Links.)
• No specs are affected by MSYS Git, but it has its own issues.

Everything else seems to work fine.

[straight-shoota]

I understand these issues are predominantly for setting up CI testing on MSYS2? It's not so much a problem for using it?

[HertzDevil]

It affects the check step within a PKGBUILD file too, since tests running on MSYS2's own CI naturally depend only on other MSYS2 packages. Basically we have to add skip_fossil=1 skip_hg=1 to make test; perhaps we could add a special case for hg when $MSYSTEM is defined, but I don't know if that is worth the effort (even as a patch exclusive to the MSYS2 package repository).

[ysbaddaden]

I assume the same issues will arise for normal usages too.

[HertzDevil]

Also this spec is failing inside MSYS2:

shards/spec/integration/install_spec.cr

Lines 1285 to 1291 in ec84197

	it "fails when git is missing" do
	metadata = {dependencies: {web: "*"}}
	with_shard(metadata) do
	ex = expect_raises(FailedCommand) { run "shards install --no-color", env: {"PATH" => File.expand_path("../../bin", __DIR__), "SHARDS_CACHE_PATH" => ""} }
	ex.stdout.should contain "Error missing git command line tool. Please install Git first!"
	end
	end

The reason is that the temporary $PATH contains none of Shards itself's dependent DLLs, so running anything gives the exit code 0xC0000135 without an error message.