VectorFeatureWriterHandler: fix axisOrder issue when CRS is North/East

[jampukka]

VectorFeatureWriterHandler correctly reads GeoJSON as lon/lat to JTS x/y order. However, when generating WFS 1.1.0 <wfs:Transaction> it fails to respect the axis order defined by the EPSG definition.

No changes to any current public static function (header or functionality).

[jampukka]

Yeah, uhm, this sort of works, but only if ProjectionHelper.isFirstAxisNorth(crs); returns the correct answer. And that doesn't happen if a GeoServer with default settings (forceXY=true) is running in the same servlet container, which is not that uncommon for Oskari installations.

Currently we are outputting srsName="http://www.opengis.net/def/crs/EPSG/0/xxxx". When reading the geometry from a WFS-T request GeoServer honors the WFS 1.1.0 spec of respecting the axis order of the EPSG definition. With srsName="EPSG:xxxx" and srsName="http://www.opengis.net/gml/srs/epsg.xml#xxxx" GeoServer falls back to the assumption of forceXY=true and reads it as longitude/latitude.

If we are targeting only GeoServer WFS-T services then this whole PR could be cancelled and replaced by just changing the outputted srsName format to http://www.opengis.net/gml/srs/epsg.xml#xxxx which would align with axis order of the coordinates we output (currently always longitude/latitude). But the solution proposed in this PR is more general and more in line with WFS 1.1.0 spec and also works fine with GeoServer (as long as the Oskari's call to CRS.decode(String crs); also respects the axis order defined by the EPSG definition).

[ZakarFin]

Nice, thanks :)