Use custom class loaders to load Languagetool dependencies

[Auriga2]

Prerequisites

• Reviewed the checklist

• Reviewed feedback from the "Sonar Cloud" bot. Note that you have to wait
  for the "CI / Unit Tests") to complete first. Failed Unit tests can be
  debugged by adding the label "verbose logging" to the GitHub PR.

Description of the Change

Custom class loaders are now used to load Languagetool dependencies, to avoid indriya version conflicts.

languagetool requires indriya v1.3 or earlier while systems-common used by gt-opengis is not compatible with 1.3 and requires a later version. (v2.0.2 or latest v2.2) This caused #2054

All other approaches I've tried, like ivy configs, Maven Shade Plugin and Relocation, only works for build-time conflicts. In our scenario we need to isolate 2 versions of the same library at runtime. Using a Custom ClassLoader seems to be the only possibility.

I used ivy configs to isolate the languagetool libs into a separate folder, rather than listing all the transient dependencies of languagetool in the code. The latter could cause version conflicts, as Ivy might resolve to different versions than those we have hard-coded. On the other hand ivy configs duplicates the common transient libraries.

I am loading only the Languagetool dependencies separately, keeping the rest of the constellation intact, to avoid too much complications, and when the Languagetool developers fix their issue we can easily revert the changes. (Usually both versions of the dependency is loaded using custom class loaders)

Know issues:
Undo after Ignore all doesn't work (Pre-existed)

To Do:
Find a way to reuse the common transient libraries.

Alternate Designs

• Fix the bug in org.languagetool
• Use a different spell check library

Why Should This Be In Core?

Enables spell checking in enabled text fields

Benefits

Possible Drawbacks

Complex coding

Verification Process

• Spell checking works (in Data access view)
• Schema view loads without any exception
• Export to GeoPackage and Export to ShapeFile works

Applicable Issues

#870

[sonarqubecloud]

Quality Gate failed

Failed conditions
11.9% Coverage on New Code (required ≥ 80%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE