Don't delete shared memory segments if we're about to use them

[danpat]

If osrm-datastore is run an even number of times, it will set the layout back to the currently used one. This code changes the SharedDataFacade to check if the new layout is still referring to the same one. The re-initialization is only done if the timestamp has also changed.

This is a partial fix to #1888

It fixes the "simple reproduction recipe", but I can still cause errors if I run osrm-datastore and curl in tight loops. However, running osrm-datastore in a tight loop seems like a really oddball case.

[danpat]

Hmm, this doesn't seem to fix all cases. If I put osrm-routed under heavy load, then running osrm-datastore can still cause osrm-routed to hang (with high CPU usage).

[danpat]

Additional changes clear up a lot of the problems. However, if I run osrm-datastore very rapidly, I still seem to be able to trigger exceptions in osrm-routed if it's also under heavy load. However, these instances are massively decreased compared to before, so this fix is useful.

This adds slight locking overhead to queries when using the SharedDataFacade. Unfortunately, it's unavoidable overhead if we want correct behaviour, unless we want to investigate writing some kind of lock-free implementation, which is major work.