Fix off-by-one error in last_idx management

This is a relatively benign error; causing our last_idx calculations to
be slightly more favorable than they should have been, leading to
slightly inflated match scores. I think this was likely harmless,
because all matches would have benefited from this bias.

This is how the code used to look before the ill-fated 301fd661831,
which introduced a nasty matching bug. I fixed this in 5621c4e2185, but
introduced this other error in my haste; I probably should have realized
it was wrong by comparison with the pre-301fd661831 state.

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

Commit 5621c4e21854 fixed a terrible bug that affected the correctness
of the matching algorithm, but it did so at the cost of the speed of our
pathological test case (although other test cases seemed slightly
better).

  Buggy version:
                          user     system      total        real
  pathological        0.000000   0.000000   0.000000 (  0.003640)
  command-t           0.390000   0.000000   0.390000 (  0.383473)
  chromium (subset)   1.170000   0.010000   1.180000 (  0.525694)
  chromium (whole)    4.550000   0.010000   4.560000 (  1.579863)

  Fixed version:
                          user     system      total        real
  pathological        1.880000   0.010000   1.890000 (  1.887996)
  command-t           0.350000   0.000000   0.350000 (  0.348788)
  chromium (subset)   1.140000   0.010000   1.150000 (  0.504924)
  chromium (whole)    4.430000   0.000000   4.430000 (  1.516979)

After fixing this, I went back and audited the memoization code to see
if we could "have our cake and eat it too"; that is, get robust/correct
matching and keep some or all of the speed gains that we got from
memoization in the buggy version.

It turns out, we can:

                          user     system      total        real
  pathological        0.000000   0.000000   0.000000 (  0.002413)
  command-t           0.380000   0.000000   0.380000 (  0.380633)
  chromium (subset)   0.850000   0.010000   0.860000 (  0.441269)
  chromium (whole)    3.400000   0.010000   3.410000 (  1.342450)

So, we got faster on every test case in the benchmark suite. Not sure
what I was smoking when I originally wrote the memoization code; instead
of memoizing a known result at the earliest point in the haystack
string, I was doing so at the latest, which reduces the value of the
memoization.

Signed-off-by: Greg Hurrell <greg@hurrell.net>
Establish new benchmark baseline

The pathological benchmark runs too fast to be meaningful, and because
it only contains a single path, it doesn't make use of multi-threading
like the other test cases do.

So, let's set up a new baseline by adding more paths to the test case
and running it enough times for it to be within the same order of
magnitude as its immediate neighbors.

  Before:
                          user     system      total        real
  pathological        0.000000   0.000000   0.000000 (  0.002413)
  command-t           0.380000   0.000000   0.380000 (  0.380633)
  chromium (subset)   0.850000   0.010000   0.860000 (  0.441269)
  chromium (whole)    3.400000   0.010000   3.410000 (  1.342450)

  After:
                          user     system      total        real
  pathological        0.110000   0.000000   0.110000 (  0.112132)
  command-t           0.340000   0.000000   0.340000 (  0.340255)
  chromium (subset)   0.800000   0.010000   0.810000 (  0.398784)
  chromium (whole)    3.320000   0.010000   3.330000 (  1.236914)

As you can see there is some flutter between runs (the timings for the
other test cases shouldn't have changed), but I am doing best-of-three
runs for all of these, so that's as close as I can get to scientific.

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