git_handler: use repo.changelog.node instead of repo.lookup

For a repo with over 50,000 commits, this brings down the computation of
'export' from 1.25 seconds to 0.25 seconds.

To scale this to hundreds of thousands of commits, one solution might be to
maintain the mapping in a DAG data structure mirroring the changelog, over
which findcommonmissing can be used.
git_handler: fix progress reset call
git_handler: note that new commits are returned in topo order

This wasn't obvious to me at first.
git_handler: use convert_list to cache git objects

getnewgitcommits() does a weird traversal where a particular commit SHA is
visited as many times as the number of parents it has, effectively doubling
object reads in the standard case with one parent. This patch makes the
convert_list a cache for objects, so that a particular Git object is read just
once.

On a mostly linear repository with over 50,000 commits, this brings a no-op hg
pull down from 70 seconds to 38, which is close to half the time, as expected.
Note that even a no-op hg pull currently does a full DAG traversal -- an
upcoming patch will fix this.
git_handler: terminate new commit DAG traversal at known commits

Any commit in _map_git is already known, so there's no point walking further
down the DAG.

For a repo with over 50,000 commits, this brings down a no-op hg pull from 38
seconds to 2.5.