Set HGRCPATH when running hg so a user's mercurial.ini cannot reach Chorus

HgRunner.Run() spawns hg without setting HGRCPATH, so hg reads %USERPROFILE%\mercurial.ini and any other global configuration on the machine. Chorus manages the repository's own .hg/hgrc; it should not be inheriting the user's.

The scenario that makes this matter

When a Send/Receive repository goes wrong, a support person opens it in their own TortoiseHg and enables the extensions needed to fix it — strip and rebase above all. TortoiseHg's settings dialog writes those into %USERPROFILE%\mercurial.ini. From then on, every Chorus-based application on that machine inherits them.

That is mostly harmless today, because the Mercurial we ship carries those extensions. It stops being harmless with the trimmed payload in sillsdev/Mercurial4Chorus#33, which ships 18 hgext entries in place of 142. hg then writes this to stderr on every invocation:

*** failed to import extension "strip": ('error reading bytecode from
    ...\lib\hgext\__pycache__\strip.cpython-39.pyc: The system cannot find
    the file specified. (os error 2)', 'hgext.strip')

and we treat a non-empty stderr as failure in three places in HgRepository.cs:

• :1229 RetrieveHistoricalVersionOfFile throws, deleting its temp file, even though hg cat succeeded
• :1709 recover throws
• :634 merge recovery throws

The exit code is unchanged, so nothing else notices. The breakage lands on the recovery paths, on the machine of the person doing the recovering, with a message naming a missing .pyc.

The fix

HgRunner.Run() already sets environment variables for the child process:

process.StartInfo.EnvironmentVariables["PYTHONPATH"] = ...;
process.StartInfo.EnvironmentVariables["HGENCODING"] = "UTF-8";
process.StartInfo.EnvironmentVariables["HGENCODINGMODE"] = "strict";

One more line is enough:

process.StartInfo.EnvironmentVariables["HGRCPATH"] = "";

Verified against the Mercurial 7.0.1 payload. With HGRCPATH empty, hg ignores user and global configuration and the extension error disappears — while the repository's own .hg/hgrc is still read: ui.username set in .hg/hgrc still resolves. So the configuration Chorus manages keeps working and the user's stops reaching us.

Related, in the same lines

PYTHONPATH is set to library.zip inside the Mercurial folder. That file exists in the payload we ship today, but not in the one #33 introduces, so it will point at nothing once that lands.

Start at HgRunner.Run(), where PYTHONPATH, HGENCODING, and HGENCODINGMODE are set for the child process. Review the three HgRepository.cs recovery paths at lines 1229, 1709, and 634, then verify that user Mercurial configuration no longer produces extension errors while the repository's .hg/hgrc remains usable.