fileset, revset: do not use global parser object for thread safety

parse() cannot be called at the same time because a parser object keeps its
states.  This is no problem for command-line hg client, but it would cause
strange errors in multi-threaded hgweb.

Creating parser object is not too expensive.

original:
% python -m timeit -s 'from mercurial import revset' 'revset.parse("0::tip")'
100000 loops, best of 3: 11.3 usec per loop

thread-safe:
% python -m timeit -s 'from mercurial import revset' 'revset.parse("0::tip")'
100000 loops, best of 3: 13.1 usec per loop

--HG--
branch : stable
filter: add a comment so that people do not forget to update subsettable


Changeset 175c6fd8cacc moved `subsettable` from `mercurial/repoview.py` to
`mercurial/branchmap.py`. This mean that `filtertable` and `subsettable` are no
longer next to each other. So we add a comment to remind people to update both.
import-checker: refactor sys.path prefix check (issue4129)

This patch refactors the logic in contrib/import-checker.py responsible for
checking the beginnings of the paths in sys.path.  In particular, it adds a
variable that defines the set of allowed prefixes.

The primary purpose of this change is to make it easier to add more allowed
prefixes.  This will be useful in resolving issue4129, which involves making
the function list_stdlib_modules() work when run from a virtualenv.
import-checker: make test-module-imports.t work using virtualenv (issue4129)

This patch modifies contrib/import-checker.py so that test-module-imports.t
will pass if run using virtualenv.  The patch achieves this by adding two
new prefixes to the list of allowable sys.path prefixes.  The added prefixes
are the directories of two modules in the stdlib.  The modules selected are
a minimal set that allowed the return value of list_stdlib_modules() to
match the return value without virtualenv, when run on the patch author's
machine: Mac OS X 10.8, Python 2.7.6.
import-checker: backout 40f79b9a2cc8 (issue4129)

This patch backs out 40f79b9a2cc8, which caused test-module-imports.t to
be skipped when the test was run using virtualenv.  Since the test now
passes when using virtualenv, the skip is no longer necessary.
import-checker: use any() and a genexp to avoid awkward for/else construction
import-checker: suppress check-code about any()

ast is a new enough module that this script can't work on any version
of Python without any(), so we'll just use it.
util: remove unused realpath (issue4063)

util.realpath was in use for only 5 days from dbdb777502dc
until it was backed out in c519cd8f0169 because it caused
issue3077 and issue3071.
obsolete: fix bad comment

We cannot afford such extra "with" they are far too pricy.
obsolete: improve allsuccessors doc string

The fact original nodes are also yield is not obvious. We update the docstring
to highlight it.
perf: fix perfvolatilesets

The repoview's `filteredrevs` has been renamed to `filterrevs` at some point.
perf was never informed.
obsolete: add an allprecursors method mirroring allsuccessors one.

Detection of bumped changeset should use `allprecursors(<mutable>)` instead or
`allsuccessors(<immutable>)` so we need the all precursors function to exists.
obsolete: order of magnitude speedup in _computebumpedset

Reminder: a changeset is said "bumped" if it tries to obsolete a immutable
          changeset.


The previous algorithm for computing bumped changeset was:

    1) Get all public changesets
    2) Find all they successors
    3) Search for stuff that are eligible for being "bumped"
       (mutable and non obsolete)

The entry size of this algorithm is `O(len(public))` which is mostly the same as
`O(len(repo))`. Even this this approach mean fewer obsolescence marker are
traveled, this is not very scalable.

The new algorithm is:

    1) For each potential bumped changesets (non obsolete mutable)
    2) iterate over precursors
    3) if a precursors is public. changeset is bumped

We travel more obsolescence marker, but the entry size is much smaller since
the amount of potential bumped should remains mostly stable with time `O(1)`.

On some confidential gigantic repo this move bumped computation from 15.19s to
0.46s (×33 speedup…). On "smaller" repo (mercurial, cubicweb's review) no
significant gain were seen. The additional traversal of obsolescence marker is
probably probably counter balance the advantage of it.

Other optimisation could be done in the future (eg: sharing precursors cache
for divergence detection)
merge with stable