[GEO] OGC compliant polygons fail with ambiguity

This feature branch implements OGC compliance for Polygon/Multi-polygon.  That is, vertex order for the exterior ring follows the right-hand rule (ccw) and all holes follow the left-hand rule (cw).  While GeoJSON imposes no restrictions, a user that wants to specify a complex poly across the dateline must do so in compliance with the OGC spec, otherwise a polygon that spans the globe will be assumed.

Reference issue #8672

Fix orientation of outer and inner ring for polygon with holes.  Updated unit tests.  Bug exists in boundary condition on negative side of dateline.
Updating connect method to prevent duplicate edges
Computational geometry logic changes to support OGC standards

This commit adds the logic necessary for supporting polygon vertex ordering per OGC standards. Exterior rings will be treated in ccw (right-handed rule) and interior rings will be treated in cw (left-handed rule).  This feature change supports polygons that cross the dateline, and those that span the globe/map.  The unit tests have been updated and corrected to test various situations.  Greater test coverage will be provided in future commits.

Addresses #8672
Updating translation gate check to disregard order of hole vertices for non dateline crossing polys.

Updating comments and code readability

Correcting code formatting
Adding dateline test with valid lat/lon pairs

Cleanup: Removing unnecessary logic checks
Adding unit test for self intersecting polygons. Relevant to #7751 even/odd discussion

Updating documentation to describe polygon ambiguity and vertex ordering.
Adding unit tests for clockwise non-OGC ordering

Adding unit tests to validate cw defined polys not-crossing and crossing the dateline, respectively
Add index.data_path setting

This allows specifying the path an index will be at.

`index.data_path` is specified in the settings when creating an index,
and can not be dynamically changed.

An example request would look like:

POST /myindex
{
  "settings": {
    "number_of_shards": 2,
    "data_path": "/tmp/myindex"
  }
}

And would put data in /tmp/myindex/0/index/0 and /tmp/myindex/0/index/1

Since this can be used to write data to arbitrary locations on disk, it
requires enabling the `node.enable_custom_paths` setting in
elasticsearch.yml on all nodes.