Fix egregious matching bug

This was introduced six months ago in 301fd661831 ("Fix off-by-one error
in memoization indexing"). It basically meant that you could repeat any
matching character and it would be considered to match, as long as your
query string didn't exceed the available space in the haystack.

For example, given a file "foobar", the following query strings would
all match it: "foo", "fooo", "foooo", "fooooo", "fffbar" etc; but
strings such as "ffffbar" and "foooooo" would not (due to being
overlength).

This is the most egregious bug in the matcher ever, so I'm very grateful
to Pavel Sergeev (@dzhioev) for reporting it.

Alas, the fix comes with a price; while the fix brings a marginal
performance increase for most of our test cases, the "pathological"
benchmark gets distinctly slower:

  Before:
                          user     system      total        real
  pathological        0.010000   0.000000   0.010000 (  0.003380)
  command-t           0.410000   0.000000   0.410000 (  0.413851)
  chromium (subset)   1.190000   0.010000   1.200000 (  0.552776)
  chromium (whole)    4.540000   0.010000   4.550000 (  1.557351)

  After:
                          user     system      total        real
  pathological        1.750000   0.000000   1.750000 (  1.751254)
  command-t           0.380000   0.000000   0.380000 (  0.375418)
  chromium (subset)   1.170000   0.010000   1.180000 (  0.498126)
  chromium (whole)    4.470000   0.010000   4.480000 (  1.537441)

This reverses the win reported in 301fd661831, which at the time I
described as "so marked that I am almost suspicious of it". I should
have been more suspicious...

I'll keep digging into this to see if I can improve the speed of the
pathological case, but for now I just want to get this fix out as
correctness is more important than speed.

Fixes:

  https://github.com/wincent/Command-T/issues/82

Signed-off-by: Greg Hurrell <greg@hurrell.net>