Migrate location data

[literarymachine]

On several occasions we have considered to get rid of our mechanism to attach the location of certain entries to others automatically. The current logic behind this "inheritance" is that certain types of entries (e.g. Services such as repositories) don't really have a location since they live on the web. The provider of a Service has a location though. By linking the Service to its provider, our current implementation adds the provider's location to the Service behind the scenes. It does so by writing it to the Record in the GeoJSON format. The fact that two different fields contain location data has been a common source of confusion.

The approach to investigate in this issue is to attach location data only explicitly and getting rid of the inheritance mechanism.

[literarymachine]

Migrating the data and updating the schema to support multiple locations for all entry types is all that is needed in the back end, see #1954. Looking at the effects in the front end reveals that our current approach (inheriting locations) might not be that bad after all. A main UX problem I see when attaching locations directly to the entries is a loss of context. See e.g. a much used tool such as MediaWiki which would now show a lot of mini maps without explaining what they mean:

This could be solved by thinking of a way to display all locations on a single map.

Another place where the amount of location data is hard to grasp is in the input templates:

I am unsure how this could be solved.