Build chg.exe for Windows

[rmunn]

Building chg for Linux is trivial as there is already a Makefile provided. However, chg makes a lot of Linux assumptions, such as the existence of a /proc/self/exe path, which is provided by the Linux kernel. To be able to get chg's speed benefits on Windows, we'll need to port chg to Windows, replacing its Linux-based API assumptions with calls to the Windows API. This should be doable as chg is only four C files in total, but it won't be as trivial as building chg for Linux.

[rmunn]

Linuxisms that would need to change to build chg for Windows, by file:

chg.c:

• line 115: preparesockdir calls mkdir(sockdir, 0700) expecting Unix-style permissions, and checks those permissions via checking st_uid and st_mode on the result of lstat. Would need to convert this to a Windows idiom for creating a directory accessible only to the current user.
• line 139: checkruntimedir also checks st_uid and st_mode on the result of lstat. Would need to port to Windows file permissions system.
• line 150: getdefaultsockdir uses the XDG_RUNTIME_DIR and TMPDIR environment variables to decide where to put the sockets (Unix socket files) that chg will use to communicate with the hg server. Windows uses different environment variables, and probably should actually use a different RPC method entirely. (Which might involve tweaks to the hg serve command; if so, that's even more work needed)
• line 191: getrelhgcmd uses /proc/self/exe (provided by the Linux kernel) to find the pathname to the running process, so that it can find an hg command in the same folder as the chg command currently running. Windows would have a different API for that.
• line 240: execcmdserver expects the LC_CTYPE environment variable to exist; I don't know if Windows sets that. It also opens /proc/self/fd to look for any open files that need closing; Windows will need a different API. It uses execvp to start the hg server, which as far as I can tell is provided on Windows.

Rest of the files will be in separate comments.