When we have both header expression (which has to be an OR node by
construction) and a pattern expression (which could be anything), we
create a new top-level OR node to bind them together, and the
resulting expression structure looks like this:

             OR
        /          \
       /            \
   pattern            OR
     / \           /     \
    .....    committer    OR
                         /   \
                     author   TRUE

The three elements on the top-level backbone that are inspected by
the "all-match" logic are "pattern", "committer" and "author".  When
there are more than one elements in the "pattern", the top-level
node of the "pattern" part of the subtree is an OR, and that node is
inspected by "all-match".

The result ends up ignoring the "--all-match" given from the command
line.  A match on either side of the pattern is considered a match,
hence:

        git log --grep=A --grep=B --author=C --all-match

shows the same "authored by C and has either A or B" that is correct
only when run without "--all-match".

Fix this by turning the resulting expression around when "--all-match"
is in effect, like this:

              OR
          /        \
         /          \
        /              OR
    committer        /    \
                 author    \
                           pattern

The set of nodes on the top-level backbone in the resulting
expression becomes "committer", "author", and the nodes that are on
the top-level backbone of the "pattern" subexpression.  This makes
the "all-match" logic inspect the same nodes in "pattern" as the
case without the author and/or the committer restriction, and makes
the earlier "log" example to show "authored by C and has A and has
B", which is what the command line expects.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>