New wifi query algorithm: sort by dBm, cluster by distance, take first. Close #155.

First sketch of code for #155. Probably needs some more tests (notably for dBm sensitivity). Also has a couple issues to discuss in review:

  - It currently takes the first cluster that exceeds 3 elements. It _could_ cluster all networks then pick the cluster with (say) the strongest cumulative signal strength, or the cluster containing the network with the highest individual signal strength. I'm not really sure which is best here, happy to take suggestions.

  - It continues to use `decimaljson.quantize` as in the existing code, which I now notice gives slightly different results from my recently-added `models.to_degrees`. I think this is just a matter of using decimal floating point rather than binary floating point (and/or precision, rounding mode). Exhibit A:

````
In [21]: quantize(10001000) == Decimal("1.0001000")
Out[21]: True
In [22]: quantize(10001000) == 1.0001000
Out[22]: False
In [23]: quantize(10001000) == to_degrees(10001000)
Out[23]: False
In [24]: to_degrees(10001000) == 1.0001000
Out[24]: True
In [25]: to_degrees(10001000)
Out[25]: 1.0001
````
So that is not really surprising, but it suggests I ought to either change `decimaljson` to use binary floating point or change the `to_degrees` / `from_degrees` functions to use `Decimal` and banish binary fp from the codebase. Not sure how to handle this either, I'm fine either way. Binary fp is more convenient for casual coding (and modules like `math`, thus `ichnaea.geocalc`, use it) whereas decimal is more like the arithmetic the non-computer outside world of cartographers might like (and is more congruent with our quantized distance units of decimicrodrgees). Perhaps all this should be a separate bug.