- fix/tweak: "Unrecognized text" error handling now has a stricter (and at the same time slightly more flexible) check to see if the (possibly user-specified) `parseError()` handler has consumed any input while it may have attempted to 'recover' from the error. (**WARNING/NOTE**: under very particular circumstances -- including the use of a user-specified `parseError()` handler! -- the lexer run-time engine MAY exhibit "infinite loop" lockup behaviour: **when you specify your own `parseError()` which "recovers" from a lexer error by producing a lexer token or switch lexer state or pushing or popping a lexer condition, you must ensure that you either consume some input via the `lexer.input()` API or otherwise or switch lexing conditions sufficiently that your particular lexer won't get into an infinite lexing loop, both within a single `lex()` call and "infinite looping" through producing an infinite stream of lexer tokens while no further pending input is consumed.**)
- fix/tweak: "Unrecognized text" error handling now has a stricter (and at the same time slightly more flexible) check to see if the (possibly user-specified) `parseError()` handler has consumed any input while it may have attempted to 'recover' from the error. (**WARNING/NOTE**: under very particular circumstances -- including the use of a user-specified `parseError()` handler! -- the lexer run-time engine MAY exhibit "infinite loop" lockup behaviour: **when you specify your own `parseError()` which "recovers" from a lexer error by producing a lexer token or switch lexer state or pushing or popping a lexer condition, you must ensure that you either consume some input via the `lexer.input()` API or otherwise or switch lexing conditions sufficiently that your particular lexer won't get into an infinite lexing loop, both within a single `lex()` call and "infinite looping" through producing an infinite stream of lexer tokens while no further pending input is consumed.**)

- refactor the error display code: remove duplicate code chunks = moved the inclusion of an error location description/display part of the error message inside `constructLexErrorInfo()`

- tweak: error location display message part is now included when there a possibly legal `yylloc` info; we no longer watch the `options.trackPosition` setting as that option is equivalent to having a legal `yylloc` around from the lexer engine perspective. **WARNING/NOTE**: given the current lexer code generator behaviour, this means that non-location-tracking (`options.trackPosition = true`) lexers will include line number + location tracking info in their lexer error messages until this is fixed by having a proper code stripper in the lexer generator.

GerHobbelt/jison,GerHobbelt/jison,GerHobbelt/jison,GerHobbelt/jison