[GEO] Add CRS Support to Geo Field Mappers and QueryProcessors

[nknize]

This PR adds support for indexing and searching geo_shape data in its native coordinate reference system (CRS) without having to reproject to WGS84.

The following is an example mapping configuration for indexing in UTM Zone 14 N using the EPSG CRS definition:

“properties” : {
    “location” : {
        “type” : “geo_shape”, 
        "crs": {
            "type": "name",
            "properties": {
                "name": "EPSG:32614"  // UTM Zone 14N
            }
        }
    }
}

Users pass GeoJSON with coordinates in the native UTM Zone 14N projection which will index without loss of precision or having to reproject to WGS84.
Query coordinates must be passed in the same coordinate reference system.
All projections are handled using a new Proj4J third party dependency.
This feature is licensed Gold.

todo:

• add docs
• check impact on SQL plugin

relates #23221

[elasticmachine]

Pinging @elastic/es-analytics-geo

[nknize]

Pending CI this should be ready for review

[imotov]

WRT GeoSql, supporting CRS can be a bit tricky. In GeoSql all supported CRS are described in the SPATIAL_REF_SYS table and the ID under which the CRS shows up in this table is then used everywhere in the interface to identify the CRS.

So, we will probably need to find a way to generate a comprehensive list of CRSes with stable numeric IDs, which might be a bit tricky since we generate this list dynamically. We will not be able to expose this list as a table, unless we are willing to create an internal index with them. So, instead we can add similar functionality as a command SHOW_SPATIAL_REF_SYS or something like this.

The second issues is that in GeoSql CRS id is an attribute of the geometry, so we will need to find a way to pass associate this information with the data that we get from elasticsearch.

The third issue is that we will need a way to perform a transformation of a geometry from its original CRS into another CRS specified by CRS's numeric ID, which means we will need to add a painless whitelisted method that will take 2 parameters: a CRS id and Geometry and return another Geometry converted from its original CRS into specified CRS.

[rjernst]

@nknize I jsut realized I had a couple very minor comments pending here for months. Is this PR something still being worked on that needs review?

[nknize]

Thank you @rjernst! Yes this is still being worked but it's blocked by ongoing lucene work. I can close the PR and reopen once the lucene work is done, or we can merge this under the "more dev in master" philosophy and open a separate PR to integrate the Lucene portion once ready?

[rjernst]

My preference would be close (or hold the PR open if you prefer) over pushing unfinished work to master. I only pinged here because I noticed I was marked to review. :)