[ALLI-6920] OnkiLightEnrichment: enrich records with available WGS 84 data

[kouralex]

Few notes:

1. OnkiLightEnrichment may yield many points to location_geo field in case $localData is false but only the first one is considered the centroid one (if none exists before).
2. OnkiLightEnrichment: as class variables solrLocationField and solrCenterField are initialized in the class file, I believe that pre-existing installations of RecordManager will readily use them without configuration changes. This may or may not introduce unwanted consequences.
3. Enrichment\NominatimGeocoder will now check for pre-existing centroid value and add polygon(s) to Solr location field only if the centroid is included in the polygon.
4. Additionally [related to ALLI-6920], if, for example, NominatimCoder is wanted to be applied after, let's say, MarcOnkiLightEnrichment, one must pay attention to how enrichments are added and their respective execution order: a. Globally declared enrichments added via Solr configuration enrichment array are called "first" (of course setting the enrichment stage affects this in a way), see code below: https://github.com/NatLibFi/RecordManager/blob/b7913fdcabdc6f9128e59fc0b6384af908fc0633/src/RecordManager/Base/Solr/SolrUpdater.php#L2754-L2775 b. In order to tackle some issues described in a), one could just simply add enrichments via numbers, e.g., enrichments[n] = MarcOnkiLightEnrichment; enrichments[n+1] = NominatimGeocoder; however, this method is not powerful enough to 'beat' the boundary of globally declared enrichments and datasource enrichments. Solely on the datasource configuration side, however, this would work.

All in all, please note that any Solr field value is left unchanged and may not be updated by the code - only additions are made.

[EreMaijala]

@kouralex Tsekkaa myös mysql.sql:n konflikti.