revset: fix adds/modifies/removes and patterns (issue3403)

The fast path was triggered if the argument was not like "type:value", with
type a known pattern type. This is wrong for several reasons:
- path:value is valid for the fast path
- '*' is interpreted as a glob by default and is not valid for fast path

Fast path detection is now done after the pattern is parsed, and the normalized
path is extracted for direct comparison. All this seems a bit complicated, it
is tempting to drop the fast path completely. Also, the hasfile() revset does
something similar (only check .files()), without a fast path. If the fast path
is really that efficient maybe it should be used there too.

Note that:

  $ log 'modifies("set:modified()")'

is different from:

  $ log 'modifies("*")'

because of the usual merge ctx.files()/status(ctx.p1(), ctx) differences.

Reported by Steffen Eichenberg <steffen.eichenberg@msg-gillardon.de>

--HG--
branch : stable
patch: display a nice error for invalid base85 data

Before, import was terminating with a traceback. Now it says:

 $ hg import --no-commit ../bad.patch
 applying ../bad.patch
 abort: could not decode binary patch: bad base85 character at position 66

--HG--
branch : stable
patch: include file name in binary patch error messages

 $ hg import --no-commit ../mercurial_1915035238540490516.patch
 applying ../mercurial_1915035238540490516.patch
 abort: could not extract binary data

Becomes:

 abort: could not extract "binary2" binary data

--HG--
branch : stable
patch: be more tolerant with EOLs in binary diffs (issue2870)

The only place where an trailing CR could be meaningful is in the "diff --git"
line as part of a filename, and existing code already rule out this
possibility. Extend the CR/LF filtering to the whole binary hunk.

--HG--
branch : stable
test-convert-svn-source: fix non-determinism

This test was failing randomly with:

  --- /tests/test-convert-svn-source.t
  +++ /tests/test-convert-svn-source.t.err
  @@ -35,8 +35,8 @@

     $ svnurl="file://$svnpath/svn-repo/proj%20B"
     $ svn import -m "init projB" projB "$svnurl" | fixpath
  +  Adding         projB/tags
     Adding         projB/mytrunk
  -  Adding         projB/tags

     Committed revision 1.

--HG--
branch : stable
test-subrepo-svn: fix non-determinism

The test was randomly failing with:

  --- /tests/test-subrepo-svn.t
  +++ /test-subrepo-svn.t.err
  @@ -273,10 +273,10 @@
     1 files updated, 0 files merged, 0 files removed, 0 files unresolved
     $ cd t/s
     $ svn status
  -  ? *    a (glob)
  -  X *    externals (glob)
  -  ? *    f1 (glob)
  -  ? *    f2 (glob)
  +  ?       f1
  +  ?       f2
  +  ?       a
  +  X       externals

     Performing status on external item at 'externals'* (glob)

--HG--
branch : stable
subrepo: fix default implementation of forget() (issue3404)

--HG--
branch : stable
doc: flatten description of 'matching()' predicate to be formatted well

current description of 'matching()' revset predicate can't be
formatted well on "hg help revset" output.

each descriptions for revset predicates (or something like them) are
split-ed into lines, and spaces on left side of them are stripped
before minirst processing. so, bullet list can't be nested.

this patch just flattens description of 'matching()' predicate to be
formatted well.

--HG--
branch : stable
subrepo/svn: abort on commit with missing file (issue3029)

Previous code was printing a traceback because it expected some error output
from svn. But sometimes our definition of "changed" differs with the subversion
one. For instance, subversion ignores missing files when committing. And when
there are only missing files, svn commit will be a successful no-op with no
output. Still, we should stick to our definition including missing files in
changes as doing otherwise could cause surprising behaviour for the user.

--HG--
branch : stable
subrepo/svn: improve error message on missing files

From:

  abort: failed to commit svn changes

to:

  abort: cannot commit missing svn entries

--HG--
branch : stable
rebase: preserve mq series order, guarded patches (issue2849)

The previous code was rebasing an applied series like:

  patch1 +guarded
  patch2
  patch3 +guarded
  patch4
  patch5 +guarded

into:

  patch2
  patch4
  patch1 +guarded
  patch3 +guarded
  patch5 +guarded

Reported by Lars Westerhoff <lars.westerhoff@newtec.eu>

Also rename mq.series_dirty into mq.seriesdirty, missed by 599a72895c0d, and
without effect since mq.qimport() was setting it already.

--HG--
branch : stable