.or() fails w/ err msg from branch that got furthest

note the less than optimally helpful error message in the 'use
Parsimmon.fail to fail dynamically' test, like the 'use
Parsimmon.succeed or Parsimmon.fail to branch conditionally' test
.then() after .or() also fails w/ err msg from branch...

that got furthest.

success continuations now take 2 more arguments: the furthest in the
stream any subparser of parser has ever gotten before backtracing, and
the corresponding `expected` message.

they're used by the `success` continuation that .then() passes to the
`self` parser, the arguments are then used like in .or(): to compare
against them in the failure continuation passed the `next` parser.
.or() and .then() both also have to pass them forward in the success
continuations too, of course.

so factor out from .or() HOFs that construct success and failure
continuations to pass on that will always preserve the error message
from the branch that got furthest, constructed from the onSuccess and
onFailure continuations.

also the base parsers, if they succeed, no subparser in them has ever
failed, so for `furthestFailedI` they pass in -1 (less even than 0, the
least far you could possibly fail), which any actual failure is
guaranteed to be at a larger index than and hence ignore their
`expected` message (or lack of one).
.many() also fails w/err msg from branch that got furthest

look at that sweet test case: an s-expression parser! That's basically
like a real-world parser, right?
in .times() rename msg var `failure` => `expected` #naming

convention is for `failure` to be a failure continuation callback, why
the fuck was there an error message variable named `failure`?
deal with arguments in argument order #cosmetic

in arguments lists, `newI` comes before `x` or `msg`, so logically, deal
with it first, then deal with the next argument.

Also, this matches .many()
.times() fails w/err msg from branch that got furthest

interestingly, .times() actually got simpler: instead of different
`firstFailure` and `secondFailure` continuations (depending on whether
we're repeating the `self` parser less than the minimum or maximum
number of times, respectively), since we're now keeping the failure
continuation variable `furthestFailedI` separate from the success
continuation variable `i`. Which we could've done in the first place,
but `{first,second}Failure` seemed more natural.
Merge pull request #3 from laughinghan/better-err-msgs.furthest

Better error messages: furthest