TestDictionary.testInvalidData fails [LUCENE-9079]

eg 

It seems it fails regularly. @rmuir came up with a clue 
> The test expects a ParseException (which contains offset) to be triggered for the invalid data\.
> But the offset isn't what the test expects\.
> If you look at the test and the code, there isn't anything sneaky going on here\. We just populate the ParseException with getLineNumber\.
> Does this only fail with EA JDK? Could be a JDK issue!

` NOTE: reproduce with: ant test  -Dtestcase=TestDictionary -Dtests.method=testInvalidData -Dtests.seed=89954FC6F33225B1 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=os-GE -Dtests.timezone=Pacific/Guadalcanal -Dtests.asserts=true -Dtests.file.encoding=US-ASCII`
{{   [junit4] FAILURE 0.04s J2 | TestDictionary.testInvalidData <<<
   [junit4]    > Throwable #1: java.lang.AssertionError: expected:<24> but was:<23>
   [junit4]    >        at __randomizedtesting.SeedInfo.seed([89954FC6F33225B1:61632831A7F4F9CE]:0)
   [junit4]    >        at org.apache.lucene.analysis.hunspell.TestDictionary.testInvalidData(TestDictionary.java:137)}}

---
Migrated from [LUCENE-9079](https://issues.apache.org/jira/browse/LUCENE-9079) by Mikhail Khludnev (@mkhludnev), updated Dec 11 2019

Start with TestDictionary.java at line 137 and reproduce the failure using the ant test command and seed provided. Trace how the invalid data produces its ParseException and how getLineNumber supplies the offset, then compare the behavior across the relevant JDKs. Done means testInvalidData is stable and passes with the expected offset.

Written by the indexing model from the issue text.