[GH-3088] Bump proj4sedona to 0.1.0

[jiayuasu]

Did you read the Contributor Guide?

• Yes, I have read the Contributor Rules and Contributor Development Guide

Is this PR related to a ticket?

• Yes, and the PR name follows the format [GH-XXX] my subject. Closes CRS Transformation - Unknown projection - SIRGAS 2000 (EPSG:5880) / Albers Equal Area Polyconic #3088

What changes were proposed in this PR?

Bumps the proj4sedona CRS engine from 0.0.8 to 0.1.0 (single proj4sedona.version property in the root pom.xml, inherited by all modules).

0.1.0 completes the proj4js projection port — it now implements all 34 map projections, including Polyconic (+proj=poly), and overhauls CRS parsing/serialization (PROJ string, WKT1, WKT2, PROJJSON).

This fixes #3088: EPSG:5880 (SIRGAS 2000 / Brazil Polyconic) is a +proj=poly CRS. 0.0.8 lacked the Polyconic projection, so ST_Transform to/from EPSG:5880 failed on the default proj4sedona path and only worked when spark.sedona.crs.geotools=all forced the GeoTools fallback. With 0.1.0 the transform succeeds natively, so the workaround is no longer required.

How was this patch tested?

• Added a regression test in FunctionsProj4Test transforming a Brasília point WGS84 ↔ EPSG:5880 and asserting the projected coordinates and an exact round-trip. Reference values from pyproj 3.7.2 / PROJ 9.5.1 (5653463.7342, 8243016.2220).
• Ran the full FunctionsProj4Test suite against the 0.1.0 artifact from Maven Central: 43/43 pass (42 existing + the new case), no regressions from the bump.
• Verified EPSG:5880 resolves offline through proj4sedona's built-in CRS provider (no network dependency introduced).

Did this PR include necessary documentation updates?

• No, this PR does not affect any public API so no need to change the documentation.

[jiayuasu]

Fixed the CI failures in CrsRoundTripComplianceTest (all 7 were in that one raster CRS round-trip test; the vector transform path and the new EPSG:5880 case are green). They fell into two groups:

Capability gains (fixed here). testExportFails_Krovak_2065 and testExportFails_HotineObliqueMercator_2056 asserted these projections were unsupported by proj4sedona (export must fail). 0.1.0 adds Krovak variants and Hotine Oblique Mercator PROJ-string serialization, so both now export and round-trip stably — the negative tests are converted to positive assertProjRoundTrip checks (and the now-unused assertExportFails helper removed).

Raster CRS-bridge path divergence (tracked separately). Five PROJ-format round trips (EPSG:5070, 3577, 27700, 28992, 3111) are no longer byte-idempotent, because Sedona's raster CRS bridge exports a CRS differently depending on whether it arrived as a +datum= code or a +towgs84=/raw PROJ string — a pre-existing inconsistency that 0.0.8's coarser output masked and 0.1.0's more PROJ-correct serialization exposed. Transforms are unaffected (this is byte-stability of the exported CRS string), and the PROJJSON/WKT1/WKT2 round trips for the same CRSs still pass. Marked @Ignore referencing #3103, which has the full diagnosis and repro.

CrsRoundTripComplianceTest now runs 81 / 0 failures / 5 skipped locally; spotless and the pre-commit hooks pass.