Upstream tests for parser exceptions to the cucumber gherkin testdata

[stof]

Our testsuite covers many cases of invalid data in our ParserExceptionsTest.

Many of those cases are not covered by the bad data of the cucumber gherkin testsuite.
We should upstream those tests to cucumber, to ensure that the handling of such invalid data is indeed consistent with official parser. Having shared regression tests is better than having them only for our own project.

Once upstreamed (and released upstream so that our testsuite runs those new upstream tests), we should probably delete those tests from ParserExceptionsTest as there is no need to test those things twice.

[acoulton]

And note that some of our exception tests are based on examples that are explicitly allowed in upstream cucumber/gherkin

[stof]

Those tests would then be cases for which we create a cucumber-parity issue in the issue tracker (if we don't have it yet), and they will eventually be gone.
but that's indeed a good catch until we reach parity.

[acoulton]

Indeed - the majority do have parity issues and I'm on the case.

Just noting in case anyone else picks up this ticket without realising how these things inter-relate.

[stof]

Note that this might help (a bit) cucumber regarding cucumber/gherkin#53 (the low number of tests for bad input probably contributes to the low code coverage situation as it means error code paths are not covered).