Draft: Allow disabling the accuracy threshold

Move the accuracy check for LocationUpdated signal emission on new locations from GClueLocator to GClueServiceClient. Add a new boolean client property DisableAccuracyThreshold which allows disabling this check. Also add this property to GClueSimple and its new_with_thresholds constructor.

The motivation for this change is to allow clients to receive location updates from sources which report accuracy values larger than the resolution of the source.

A concrete example is recording (GPX) tracks using the wifi source. The accuracy values reported by Mozilla Location Services are typically on the order of 100 m, whereas when moving, the returned coordinates change every 20 m or so. Currently GeoClue emits the LocationUpdated signal only when the distance from previous location is larger than the accuracy, and so is throwing away a large fraction of perfectly usable data.

This could be fixed if GeoClue would have access to both accuracy and resolution, but unfortunately it does not. Sources like MLS return the absolute accuracy for a single location and for sequential location fixes this overestimates the resolution.

I think GeoClue clients can be divided into two types: Some want a signal only when location has definitely changed within the requested accuracy class and thresholds (gnome-weather, nightlight etc.) and others are interested in getting the absolutely latest location (navigation) or want to track movement as accurately as possible.

The first type of apps are currently served well by GeoClue and do not need to change anything (except apps using GClueSimple.new_with_thresholds).

The second type of apps can now set the DisableAccuracyThreshold to true and in addition they can set a non-zero DistanceThreshold to avoid dealing with locations which are really duplicated within some resolution.

The use of GClueSimple.new_with_thresholds seems to be mostly limited to the Vala API at the moment, so I think it's still safe to change it. The apps will need a one line patch like the last one in this stack, but that's the price to pay for using an unreleased API.