hgrepo: expose git handler as a property

This and upcoming patches have the goal of initializing a GitHandler just once
for a Mercurial repo.
hgrepo.pull: use githandler property
hgrepo.push: use githandler property
hgrepo.findoutgoing: use githandler property
hgrepo._findtags: use githandler property
hgrepo.tags: use githandler property

Currently we call hgrepo.tags() separately for each tag. (This should be fixed
at some point.) This avoids initializing a separate git handler for each tag.

For a repository with over 150 tags, this brings down a no-op hg pull by 0.05
seconds.
gitrepo.listkeys: use githandler from localrepo

Previously we'd load the git and hg maps twice on separate git handler objects.
This avoids that.

For a repo with over 50,000 commits, this brings a no-op hg pull down from 2.45
seconds to 2.37.
gitrepo: drop unused _initializehandler function and handler property

Also drop the GitHandler import. All this now lives on hgrepo.
gimport: use githandler from repo
gexport: use githandler from repo
gclear: use githandler from repo
findcommonoutgoing: use githandler from repo
getremotechanges: use githandler from repo
revset_fromgit: use githandler from repo
revset_gitnode: use githandler from repo
gitnodekw: use githandler from repo

Since a fresh GitHandler is no longer created for every commit, this speeds up
the {gitnode} template massively.

For a repo with over 50,000 commits, the command

hg log -l 10 --template '{gitnode}\n'

speeds up from 2.4 seconds to 0.3.
hg2git: move parse_subrepos to top level

durin42 expressed a desire for this function to be at the top level.
hg2git: fix subrepo handling to be deterministic

Previously, the correctness of _handle_subrepos was based on the order the
files were processed in. For example, consider the case where a subrepo at
location 'loc' is replaced with a file at 'loc', while another subrepo exists.
This would cause .hgsubstate and .hgsub to be modified and the file added.

If .hgsubstate was seen _before_ 'loc' in the modified/added loop, then
_handle_subrepos would run and remove 'loc' correctly, before 'loc' was added
back later. If, however, .hgsubstate was seen _after_ 'loc', then
_handle_subrepos would run after 'loc' was added and would remove 'loc'.

With this patch, _handle_subrepos merely computes the changes that need to be
applied. The changes are then applied, making sure removed files and subrepos
are processed before added ones.

This was detected by setting a random PYTHONHASHSEED (in this case, 3910358828)
and running the test suite against it. An upcoming patch will randomize the
PYTHONHASHSEED in run-tests.py, just like is done in Mercurial.
tests: upgrade run-tests.py

This is the version in Mercurial rev 87e52e642562, plus a patch to make
--with-hg work for system hg (sent upstream). Importantly, this gets us the
hash seed randomization we need for bugs like the one fixed by the parent
commit to be detected.
version: drop support for Mercurial 1.9.3

Upcoming patches will clean up some code that makes hg-git work with Mercurial
versions < 2.0.