Fix lat/lon axis flip for sources with an explicit srs tag

[iandees]

Root cause

ogr_source_to_csv() in openaddr/conform.py builds inSpatialRef for the explicit-srs case like this:

inSpatialRef = osr.SpatialReference()
inSpatialRef.ImportFromEPSG(int(srs[5:]))

but never calls SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) on it, while outSpatialRef a few lines later correctly does. GDAL 3 defaults new SpatialReference objects to authority-compliant axis order, which for geographic CRSes (e.g. EPSG:4326, EPSG:4269, and reportedly the Slovenia source's declared SRS) is (lat, lon) instead of the traditional GIS (lon, lat) order. Since only the output SRS was patched to traditional order and the input SRS was not, the coordinate transform silently swapped lat/lon for any source using an explicit srs: tag — this matches the issue's own diagnosis thread, where removing the srs tag "fixed" the flip.

The sibling function _transform_to_4326() already sets the axis mapping strategy on both the input and output spatial refs, so it wasn't affected. ogr_source_to_csv only did it for the output side.

Fixes #26.

Fix

Add the same GDAL-3-guarded SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) call to inSpatialRef right after it's built from the explicit srs tag, matching the existing style used for outSpatialRef and in _transform_to_4326.

Verification

• Reproduced the bug first: added a regression test (test_lake_man_shp_epsg4269_axis_order) using a shapefile fixture with coordinates in ordinary (lon, lat) order and an explicit "srs": "EPSG:4269" tag (a geographic CRS, same class as the Slovenia source). With the fix reverted, this test fails with the exact symptom described in the issue — lat and lon swapped (-122.2592497 != 37.8026126). With the fix applied, it passes.
• While running the full openaddr.tests.conform suite, discovered that the pre-existing test_lake_man_gml test (a GML source that also uses an explicit "srs": "EPSG:4326" tag) had its expected coordinates already swapped — i.e. it had encoded this exact bug as "expected" behavior, unlike every other conform test in the file which expects [lon, lat] GeoJSON order. Corrected that test's assertions to the proper [lon, lat] order as part of this fix.
• Ran the full suite via the repo's test image: docker run --rm -v "$(pwd)":/usr/local/src/batch-machine -w /usr/local/src/batch-machine batch-machine-test:latest python3 -m unittest openaddr.tests.conform -v — all 66 tests pass.