[BUG] "git --literal-pathspecs blame" broken in master

[Jeff King <peff@peff.net>]

There seems to be a bad interaction with --literal-pathspecs and the
pathspec magic that is in master. Here's an example:

  [setup]
  $ git init
  $ echo content >':(foo)bar'
  $ git add . && git commit -m foo

  [with git v1.8.4]
  $ git blame ':(foo)bar'
  ^6b07eb4 (Jeff King 2013-10-24 22:59:02 -0400 1) content
  $ git --literal-pathspecs blame ':(foo)bar'
  ^6b07eb4 (Jeff King 2013-10-24 22:59:02 -0400 1) content

So originally "blame" did not handle pathspec magic at all, and
--literal-pathspecs did nothing. So the former is arguably buggy, but
the latter did the right thing (if only by accident :) ).

Then along came 9a08727 (remove init_pathspec() in favor of
parse_pathspec(), 2013-07-14), and we get:

  $ git blame ':(foo)bar'
  fatal: Invalid pathspec magic 'foo' in ':(foo)bar'
  $ git --literal-pathspecs blame ':(foo)bar'
  fatal: Invalid pathspec magic 'foo' in ':(foo)bar'

The first is an improvement, because we are now consistent with other
pathspec handling in git. But the latter is a regression; we are not
respecting the literal pathspec flag.

We get another change with a16bf9d (pathspec: make --literal-pathspecs
disable pathspec magic, 2013-07-14), which I would think would fix
things, but doesn't.

  $ git blame ':(foo)bar'
  fatal: Invalid pathspec magic 'foo' in ':(foo)bar'
  $ git --literal-pathspecs blame ':(foo)bar'
  fatal: :(foo)bar: pathspec magic not supported by this command: 'literal'

The first one remains good, but the second one is still broken. I
haven't dug further yet, but I thought it might be a bit more obvious to
you.

-Peff