**Why?** Allow JS in contrib modules to take advantage of
now decoupled map instantiation code to create canonically
extensible/styled maps where the life-cycle of those maps
is controlled by the contrib module JS code.
For example, a contrib module's controller can return;
```php
return [
'map-prototype' => [
'#type' => 'farm_map',
'#attributes' => [
'id' => 'example-tool-map-prototype',
'data-map-instantiator' => 'example-tool',
],
],
];
```
Then create map instances from custom JS like this;
```js
const mapPrototypeElement = document.getElementById('example-tool-map-prototype');
const mapElement = mapPrototypeElement.cloneNode();
mapElement.removeAttribute('id');
myParentContainer.appendChild(mapElement);
const mapInstance = Drupal.behaviors.farm_map.createMapInstance(mapElement, mapElement, 'example-tool-map-prototype', {});
```
**Why?** There were a bunch of places where farmOS implicitly depends
on the id of the map element to look up settings and access the map
element after the map is instantiated.
This change makes it so there is only one place in the JS that depends
on the map id to dereference the drupalSettings and assign them under
`instance.farmMapSettings` so behaviors can access them.
**Why?** It should be possible to leverage the farm_map
module's extension mechanism and default styling without
necessarily giving it full control over when the map
instance gets created.
Currently, the FarmMap render element uses the 'farm-map'
CSS class to inform the JS code in `farm_map.js` that it should
instantiate the map. This is problematic since that CSS class
is also used for styling and there's a bunch of code in the
FarmMap render element and in `farm_map.js` which should
be common to pretty much all farmOS maps.
To fix that, this change introduces a new [data attribute] which
is used instead of the CSS class to signal the JS code in `farm_map.js`
that it should actually instantiate the map.
[data attribute]: https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes
Reducing changes a GeometryCollection of Polygons into a
MultiPolygon, which is not our intention in most cases.
If code needs a reduced geometry it can call the reduceWkt()
method intentionally.
This can be the future home of import-related support code.
CSV importers can be built here, or in sub-modules of this.
The KML importer can move here, and future importers for
GeoJSON and other formats may also be added.
