pathspec: speed up "vanilla" pathspec access

When we diff two trees with a set of pathspecs, we walk
through the trees linearly, and apply each pathspec to each
entry. This means we do `O(paths * pathspecs)` comparisons
for each tree. If we assume that the number of pathspecs may
approach the number of paths, this is `O(n^2)` in the number
of paths. We have to do it this way in the general case
becaause pathspecs may be arbitrary fnmatch expressions, and
we cannot create any meaningful index.

However, it is common that all of the pathspecs are vanilla
prefixes (e.g., "git.c" or "Documentation/") that do not use
any wildcards or magic features. In such a case, we can
index the pathspec list to give us faster lookups.

This patch automatically detects such a vanilla pathspec,
keeps the list sorted, and teaches the tree-diff machinery
to binary search the sorted list, resulting in `O(n log n)`
comparisons. The speedup is easy to measure if you have a
large number of pathspecs:

    [before]
    $ ps=$(git ls-tree --name-only -r HEAD -- Documentation)
    $ time git log $ps >/dev/null
    real    0m6.809s
    user    0m6.764s
    sys     0m0.044s

    [after]
    $ time git log $ps >/dev/null
    real    0m1.211s
    user    0m1.176s
    sys     0m0.028s

Of course this is a contrived case, but a real script might
do something similar by filtering the ls-tree output and
asking for only a subset of the names.

We could shrink this to `O(n)` by using a constant-time data
structure like a hash table. However, it's slightly tricky
to do so as we are not matching exact strings; we need to
handle matching prefixes, as well as doing the right thing
for pathspecs that have a trailing slash.

Another `O(n)` alternative would be to walk the sorted trees
and pathspec in parallel. This would require a fair bit of
refactoring around the diff_tree code, and it gets hairy as
we deal with the tree's peculiar sorting order.

This patch aims for a simple and reasonably fast
implementation. We only teach the diff_tree to use the
optimization here, but in theory it would be suitable
anywhere that pathspecs are evaluated.

Signed-off-by: Jeff King <peff@peff.net>