**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
**Why?** In 1.x and 2.x prior to this change we were depending on
the insertion order in JS objects to make sure `instance.popup` got
populated before it is used. This change makes the order of the
behavior attachement deterministic - even with farmOS-map 2.x where
the behaviors get attached asynchronously.
