build: make the Enterprise Architect module optional via the 'ea' profile

[jdsika]

Draft for internal review in this fork, not yet proposed upstream. Targeted at next
here so the approach can be agreed before anything goes to ShapeChange/ShapeChange.
Both build paths are now verified — see Verification.

Problem

shapechange-app declares a compile-scope dependency on shapechange-ea, which compiles
against org.sparx:eaapi. That artifact ships inside an Enterprise Architect installation
and is on no public repository, so a machine or CI runner without EA cannot build the app
module at all:

Could not resolve dependencies for project net.shapechange:shapechange-ea:jar:4.1.0-SNAPSHOT
dependency: org.sparx:eaapi:jar:17.0.1704 (compile)
Could not find artifact org.sparx:eaapi:jar:17.0.1704 in central

This blocks contributors and any CI for input types that have nothing to do with EA — SCXML
in particular, which is the path this project's own updateOrCreateScxmlResources mechanism
exists to enable.

Why the code doesn't need it

The architecture already treats EA as pluggable. DefaultModelProvider resolves the model
reader by class name:

} else if (modelTypeIn.equalsIgnoreCase("ea7")) {
    modelType = "de.interactive_instruments.shapechange.ea.model.EADocument";
...
theClass = Class.forName(modelType);

SqlDdl does the same for DatabaseModelWriterEA. Neither shapechange-core nor
shapechange-app holds a compile-time reference to any EA type — shapechange-app is a
single source file (Main.java) with no org.sparx import anywhere. Only the Maven
wiring forces EA on everyone.

Change

• Root POM — shapechange-ea moves into an ea profile, activated by the absence of
  the skipEa property, so the default reactor is byte-for-byte the same as before.
• shapechange-app/pom.xml — the shapechange-ea dependency and the EA-only resource
  copy move into the same profile.
• BasicTest — the single EA type in the test sources (EAModelDiff, used by the
  private similarEaRepo helper for .qea comparisons) is resolved by class name, mirroring
  how the main code loads EA classes. Without the module those comparisons now fail with a
  message naming the cause, instead of the whole test tree failing to compile.

mvn -DskipEa … produces a distribution supporting every non-EA input type (SCXML, XMI,
GCSR). Selecting inputModelType=EA7 in such a build fails at model load, where the lookup
happens.

Verification

Ubuntu 24.04 (WSL2), OpenJDK 21.0.11, Maven 3.9.16 — run both with Enterprise Architect
17 installed (its eaapi.jar registered locally via install:install-file) and without it:

Check	Default (EA)	-DskipEa
Reactor	4 modules, incl. shapechange-ea — unchanged	ShapeChange, shapechange-core, shapechange-app
mvn install	SUCCESS (all three modules)	SUCCESS
OntologyTest#testQualifiedCardinalityRestrictions	1 run, 0 failures	1 run, 0 failures
Full suite	255 run, 14 failures, 78 errors, 34 skipped	identical: 255 / 14 / 78 / 34

The full-suite numbers are the same on both paths, so this change alters no test outcome.

The regression-test row matters beyond this PR: it backs ShapeChange#756, and without this
change that command cannot be executed at all on a machine without EA.

Accounting for every failure, on both paths

Cause	Count	Evidence
Pre-existing Saxon test-classpath exclusion in this module's surefire config (classpathDependencyExcludes → net.sf.saxon:Saxon-HE)	78 errors + 12 failures	With the exclusion lifted: CodelistsTest 3/3, FeatureCatalogueTest 16/16, OutputProcessingTest 2/2 pass
External sqldiff binary absent	2 failures	Cannot run program "sqldiff" in the GeoPackage tests
This change	0	Identical counts with and without EA

The skipped tests

34 tests skip, the same classes on both paths, including the EA-backed ones
(TaggedValueEaInputTransformerTest, SQLDatabaseModelTest, UmlModelTest,
ArcGISWorkspaceTest). EA's native COM layer is not reachable from a Linux JVM, so they
skip whether or not the module is built — no EA test starts failing silently under
-DskipEa. A reviewer on Windows with EA should confirm those still run there.

Noted, deliberately not fixed here

The Saxon exclusion makes every XSLT-producing target fail under mvn test, with or without
EA. That looks worth a separate look; it is out of scope for this change and untouched.

[jdsika]

Filed upstream as ShapeChange#757, rebased onto current upstream/next so it is a single commit on a current base (ShapeChange#756 having landed in the meantime). Both paths were re-verified on the rebased commit before filing — default (EA installed): all three modules build, regression test green; -DskipEa: two modules build, same test green; full suite identical on both paths (255/14/78/34).

Keeping this fork PR open as the internal record until ShapeChange#757 is resolved.