parsers: use 'k' format for Py_BuildValue instead of 'n' because Python 2.4

'n' was introduced in Mercurial in 2b5940f64750 and broke Python 2.4 support in
mysterious ways that only showed failure in test-glog.t. Py_BuildValue failed
because of the unknown format and a TypeError was thrown ... but it never
showed up on the Python side and it happily continued processing with wrong
data.

Quoting https://docs.python.org/2/c-api/arg.html :

  n (integer) [Py_ssize_t]
    Convert a Python integer or long integer to a C Py_ssize_t.
    New in version 2.5.

  k (integer) [unsigned long]
    Convert a Python integer or long integer to a C unsigned long without
    overflow checking.

This will use unsigned long instead of Py_ssize_t. That is not a good solution,
but good is not an option when we have to support Python 2.4.

--HG--
branch : stable
files: fix example list syntax

--HG--
branch : stable
help/config: fix typo

--HG--
branch : stable
i18n: add hint to digest mismatch message

--HG--
branch : stable
run-tests: output diffs with only forward slashes

This removes some gratuitous variance when testing on Windows with
test-run-tests.t.

--HG--
branch : stable
revset: avoid O(n) lookup of invalid revision in rev()

ba89f7b542c9 was not the final version of that patch.  It was really slow
because `l not in repo.changelog` iterates revisions up to `l`.  Instead,
rev() should utilize spanset.__contains__().

revset #0: rev(210000)
0) wall 0.000039 comb 0.000000 user 0.000000 sys 0.000000 (best of 67978)
1) wall 0.002721 comb 0.000000 user 0.000000 sys 0.000000 (best of 1055)
2) wall 0.000059 comb 0.000000 user 0.000000 sys 0.000000 (best of 45599)
(0: 3.2-rc, 1: ba89f7b542c9, 2: this patch)

Note that the benchmark result described in ba89f7b542c9 is wrong because
it is the one of the initial version.

--HG--
branch : stable
extra : rebase_source : 80827d9185dc26f67481f0a07c1265584ac67433