determine_wants: factor ref filtering code out into a separate function

This will be used in another context in an upcoming patch.
import_tags: don't import tags that don't have an hg commit equivalent

The theme of this and upcoming patches is that relying on self.git.object_store
to figure out which commits/tags/bookmarks to import is not great. This breaks
if the git repo is manually put in place (as might be done in a server-based
replication scenario), or if a partial fetch pulled too many commits in for
whatever reason. Indeed we were just about always pulling an entire pack in,
because listkeys for bookmarks currently calls fetch_pack without any
filtering. (This is probably a bug and should be fixed, but this series doesn't
do that.)

Instead, rely on whether we actually imported the commit into Mercurial to
determine whether to import the tag. This is clean, straightforward, and
clearly correct.

There is a whole series of bugs in this code that any test case for this would
hit -- an upcoming patch will include a test for all these bugs at once.
update_remote_branches: don't store refs that don't have an hg equivalent

Same reasoning as previous patch, and same reason why this patch doesn't
include a test.
update_hg_bookmarks: don't update bookmarks that don't have an hg commit

Still more bugs to fix.
git_handler: base 'no changes found' message on commits, not on heads

Since Mercurial is commit-oriented, the 'no changes found' message really
should rely on what new commits are in the repo, not on new heads. This also
makes an upcoming patch much simpler.

Since everything around this code is completely broken anyway, writing a test
for this that doesn't trigger other bugs is close to impossible. An upcoming
patch will include tests.

The test output change is for an empty clone -- the output is precisely how
vanilla Mercurial treats an empty clone.
import_git_objects: return number of commits imported

This will be used in an upcoming patch.
git_handler.fetch: actually return number of heads added or removed

The return value as implemented in git_handler.fetch was pretty bogus. It used
to return the number of values that changed in the 'refs/heads/' namespace,
regardless of whether multiple values in there point to the same Mercurial
commit, or whether particular heads were even imported. Fix all of that by
using the actual heads in the changelog, just like vanilla Mercurial.

The test output changes demonstrate examples where the code was buggy.
git_handler.fetch: only import commits reachable from requested heads

Previously we'd attempt to import every single reachable commit in the Git
object store.

The test adds another branch to the Git repo and doesn't import it until much
later. Previously we'd import it when we ran `hg -R hgrepo pull -r beta`. Now
we won't.
test-pull.t: add test for no-op pull
safebranchrevs: handle changelog having no commits

The usage of getattr was unsafe. Use hgutil.safehasattr instead.
util.safehasattr has been around since Mercurial 2.0.

This also fixes the formerly disabled test in test-pull.t.