EthiopianDateParser: dateRegex2/3 never match due to a capture-group arity mismatch #851

Split out from #845 (item C), which bundles several distinct EthiopianDateParser bugs together — this issue tracks just this one so it can be closed independently of the others.

dateRegex2 and dateRegex3 in core/src/main/scala/org/dbpedia/extraction/dataparser/EthiopianDateParser.scala each declare 4 capturing groups:

private val dateRegex2: Regex =
  s"""$prefix($monthsName)[\s/-](\b(0?[1-9]|[12][0-9]|3[01])\b)[\s/-](\d{4}|[\u1369-\u137C]+)$postfix""".r

private val dateRegex3: Regex =
  s"""$prefix(\b(0?[1-9]|[12][0-9]|3[01])\b)[\s/-]($monthsName)[\s/-](\d{4}|[\u1369-\u137C]+)$postfix""".r

The extra group comes from wrapping \b(...)\b in its own outer parens — redundant, since \b is a zero-width assertion and the day value is already captured by the inner group.

But catchGeezDate destructures each match into exactly 3 variables:

for (dateRegex2(month, day, year) <- List(dateString)) { return Some((year, month, day)) }
for (dateRegex3(day, month, year) <- List(dateString)) { return Some((year, month, day)) }

Regex.unapplySeq requires the extractor pattern's arity to match the regex's group count exactly. A 4-group regex bound to a 3-variable pattern never matches — so dateRegex2 and dateRegex3 (2 of the parser's 5 regexes) have been dead code since they were written; only dateRegex1, dateRegex4 and dateRegex5 can ever fire.

Fix: drop the outer, redundant capturing parens, bringing both regexes to 3 groups without changing what either matches. PR: #850.

Verification: standalone Java regex check mirroring the exact pattern structure (java.util.regex has the same group-counting semantics scala.util.matching.Regex wraps) — Pattern.compile(...).groupCount() is 4 before the fix, 3 after, and both patterns still match their intended date shapes unchanged. No Scala/sbt toolchain available locally to run the project's own test suite.