fix(jts): align GEOMETRYCOLLECTION with MULTIPOLYGON WKT parse

[arimu1]

Summary

• Fixes inconsistent WKT parsing when a self-intersecting MULTIPOLYGON is accepted alone but rejected inside a GEOMETRYCOLLECTION (Validation for self-intersection WKT Multipolygon fails at the WKTReader, while works when wrapped in a GEOMETRYCOLLECTION #232).
• JtsMultiShapeBuilder now returns a single child shape unchanged (no re-wrap/re-validate) and uses makeShape for homogeneous Multi* merges, matching JtsMultiPolygonBuilder and siblings.
• Adds a regression test using JtsSpatialContext.GEO and both WKT strings from the issue.

Test plan

• mvn test (full suite, JDK 17)
• Manual repro: bare MULTIPOLYGON and wrapped GEOMETRYCOLLECTION both parse successfully on JtsSpatialContext.GEO

Contributor notes

• Eclipse ECA: not yet signed by the human author — please complete at https://www.eclipse.org/legal/ECA.php before merge if required by project policy.

Fixes #232

[dsmiley]

It's not clear why this check is here, relative to the fix. If this is an unrelated optimization, it could go at the start of build(); yes?

[arimu1]

I rechecked #232 against current master (5c9e2ef8) and against this branch, on Temurin 21 and JBR 17.

MULTIPOLYGON (((5 5, 10 5, 10 10, 5 5)), ((6 6, 10 5, 10 10, 6 6))) and the same polygon wrapped in GEOMETRYCOLLECTION both throw:

InvalidShapeException: Self-intersection at or near point (6.0, 6.0, NaN)

That result is the same with and without the JtsMultiShapeBuilder change. The 0.8 asymmetry is already gone on master. The new test expected both parses to return a shape, which is why build (8), build (11), and build (21) fail at JtsWktShapeParserTest line 148. JDK 17 in CI passes that test because that run accepts the geometry; both forms still agree there.

Closing this. The shapes.size() == 1 check is not what makes the two forms agree on master. I can add a regression that only asserts the two forms agree, with no builder change, if you want that pinned.