Blowing away the cache of eSPPFs between runs of the parser.  This
should fix issue #389, which seems to be caused when a skipped range
of whitespace occurs in two runs of the parser, starting at exactly
the same character offset but containing different numbers of lines.
Moreover, it must precede some nullable production of the grammar.
Then the eSPPF cache already has an eSPPF for that character offset,
but its line-numbering is incorrect for the new parse, leading to
bogus output locations and potentially leading to well-formedness
errors later on (which rely on that position information being precise).