Bugzilla

I've been able to squash together some MSYS2 packages and making a functioning environment, but I've got some notes so far:
* On first-start, msys2 prints some information and some confusing non-errors about permissions:
```
mkdir: cannot change permissions of '/dev/shm': Permission denied
mkdir: cannot change permissions of '/dev/mqueue': Permission denied
'C:\Windows\system32\drivers\etc\hosts' -> '/etc/hosts'
'C:\Windows\system32\drivers\etc\protocol' -> '/etc/protocols'
'C:\Windows\system32\drivers\etc\services' -> '/etc/services'
'C:\Windows\system32\drivers\etc\networks' -> '/etc/networks'
MozillaBuild Install Directory: C:\mozillabuild-stage\mozilla-build\

Mitch@mitch-home-windows-desktop MSYS ~
$
```
I've provided an [upstream patch](https://github.com/msys2/MSYS2-packages/pull/2700) for the confusing non-errors.
* There's some funk around the different possible terminals: the main two being the Windows Command Prompt and the MSYS2-recommended one being MinTTY. _In general_, mintty behaves better with msys2-native (linux-y) software, while the Command Prompt is better at Windows-native software.
    * If using mintty and Windows-native Python, we need to use [`winpty`](https://github.com/rprichard/winpty) to manage signals (otherwise Python thinks it's being run in a non-interactive environment). Unfortunately, CTRL-C doesn't work in `./mach bootstrap` - additional investigation into _why_ is needed.
    * If using mintty and MSYS Python, our existing code will break because the platform is changing (e.g.: `platform.uname()`, all of our "is windows" checks, etc). I _really_ don't want to have to (significantly) change the tree to port to msys2.
        * Related: I'm guessing that MSYS Python will be slower than "windows-native" Python, which will make Mach and potentially the build slower in a significant way. That's just a guess, though
    * We can go back to using MSYS with the Command Prompt, as we do with MSYS1, but:
        * There's one bug with `hg` where color codes are erroneously printed, but that's workaroundable by changing `TERM` from MSYS2's preferred value of `"xterm-256color"` to MSYS1's preferred value of `"cygwin"` (which could cause other side-effects)
        * `hg show work` still doesn't work in Python 3 + Command Prompt. Investigation is needed to determine why.
        * Out of the different combinations here, the msys software we use is much more likely to behave within mintty than within the Command Prompt, so I'd prefer not to fall back to Command Prompt if possible.
* [Mercurial 6.0 is coming out "soon"](https://www.mercurial-scm.org/wiki/Release6.0) with "Lots of Windows fixes" (!), but it doesn't affect any of the issues listed above

I've been able to squash together some MSYS2 packages and making a functioning environment, but I've got some notes so far:
* On first-start, msys2 prints some information and some confusing non-errors about permissions:
```
mkdir: cannot change permissions of '/dev/shm': Permission denied
mkdir: cannot change permissions of '/dev/mqueue': Permission denied
'C:\Windows\system32\drivers\etc\hosts' -> '/etc/hosts'
'C:\Windows\system32\drivers\etc\protocol' -> '/etc/protocols'
'C:\Windows\system32\drivers\etc\services' -> '/etc/services'
'C:\Windows\system32\drivers\etc\networks' -> '/etc/networks'
MozillaBuild Install Directory: C:\mozillabuild-stage\mozilla-build\

Mitch@mitch-home-windows-desktop MSYS ~
$
```
I've provided an [upstream patch](https://github.com/msys2/MSYS2-packages/pull/2700) for the confusing non-errors.
* There's some funk around the different possible terminals: the main two being the Windows Command Prompt and the MSYS2-recommended one being MinTTY. _In general_, mintty behaves better with msys2-native (linux-y) software, while the Command Prompt is better at Windows-native software.
    * If using mintty and Windows-native Python, we need to use [`winpty`](https://github.com/rprichard/winpty) to manage signals (otherwise Python thinks it's being run in a non-interactive environment). Unfortunately, CTRL-C doesn't work in `./mach bootstrap` - additional investigation into _why_ is needed.
    * If using mintty and MSYS Python, our existing code will break because the platform is changing (e.g.: `platform.uname()`, all of our "is windows" checks, etc). I _really_ don't want to have to (significantly) change the tree to port to msys2.
        * Related: I'm guessing that MSYS Python will be slower than "windows-native" Python, which will make Mach and potentially the build slower in a significant way. That's just a guess, though
    * We can go back to using MSYS with the Command Prompt, as we do with MSYS1, but:
        * There's one bug with `hg` where color codes are erroneously printed, but that's workaroundable by changing `TERM` from MSYS2's preferred value of `"xterm-256color"` to MSYS1's preferred value of `"cygwin"` (which could cause other side-effects)
        * `hg show work` still doesn't work in Python 3 + Command Prompt. Investigation is needed to determine why.
        * Out of the different combinations here, the msys software we use is much more likely to behave within mintty than within the Command Prompt, so I'd prefer not to fall back to Command Prompt if possible.
* [Mercurial 6.0 is coming out "soon"](https://www.mercurial-scm.org/wiki/Release6.0) with "Lots of Windows fixes" (!), but I didn't find that it affected any of the issues listed above