largefiles: fix off-by-one error on pull --all-largefiles

Test output is changed in a case where one revision was pulled, but because of
the off-by-one error it thought that 0 revisions were pulled ... and because of
another bug it thus (tried to) fetch largefiles for all revisions.

After this change it no longer reports failure when it failed while trying to
fetch largefiles it shouldn't fetch.  Largefiles that it shouldn't fetch but
managed to fetch anyway will now correctly be missing later on.

This change thus resolves some of unexplained test output introduced in
1e4eb1faba6e.

--HG--
branch : stable
largefiles: fix download of largefiles from an empty list of changesets

The empty list was interpreted as all revisions - just like None is.

The empty list is now handled explicitly.

--HG--
branch : stable
tests: don't rely on broken behaviour in test-largefiles-cache.t

The test relied on the bug that 'pull largefiles from branchheads' didn't pull
any largefiles from tip revision when it seemed like no largefiles had been
checked out before.

--HG--
branch : stable
largefiles: getstandinmatcher should not depend on existence of directories

Looking for a (potentially empty) directory was not reliable - both because it
is a reasonable assumption that empty directories can be removed and because it
wasn't created in all cases ... such as when pulling to an existing repository.

--HG--
branch : stable
largefiles: don't assume that .hg/largefiles/ still exists

It might not have been created and it might have been removed.

--HG--
branch : stable
largefiles: missing largefiles should not be committed as removed

Largefiles can easily become missing - for example if it simply isn't available
or the download fail. It might even be convenient to be able to work that way
in some cases.

But commiting missing largefiles as if they had been 'hg remove'd is plain wrong.

--HG--
branch : stable
largefiles: don't let update leave wrong largefiles in wd if fetch fails

Situations where a largefile for some reason wasn't available sometimes caused
wrong largefile content and state. It has mostly been seen when interrupting
download of largefiles ... and when introducing programming errors.

Instead we now make sure to delete the old and wrong largefile. A missing file
is a well-known error condition and much more reasonable way to handle the
situation.

--HG--
branch : stable
largefiles: simplify cachelfiles - don't spend a lot of time checking hashes

cachelfiles jumped through loops to handle merges and modified files ... but it
did apparently no longer have a valid reason to do so. It should just always
make sure that the largefiles referenced from the standins are present - no
matter which actual largefile is stored in the working directory. If there is
no standin then there is nothing to fetch.

The old code usually verified the hash of all largefiles every time this
function was invoked - for examply by 'update'.

This change makes a trivial noop update 5-10 seconds faster on our repo (with
the other 50% spent doing another unnecessary hashing of all largefiles).

--HG--
branch : stable
largefiles: updatelfiles should use working dir standins, not standins from p1

This makes a difference when working directory is dirty, especially when
merging with a revision for which we don't have largefiles.

--HG--
branch : stable
templatefilters: add missing import of _

--HG--
branch : stable