Implement wifi ranging for suggested APs without scanning them

[hlxid]

Implements wifi ranging for suggested APs that the locate endpoint now returns that are around the last known position without the need to scan them first by using the MAC address and frequency of the AP.
Also lowers the ranging interval to range more often. With the default 30s scanning rate, ranging is done in an up to 3s interval if ranging is fast enough. This has been tested successfully to work.
Wifi scanning and ranging task is decoupled so that opportunistic ranging could be used to find a location faster than scanning if it scanning is very slow e.g. during first app startup.
When moving fast you still need to wait for scanning sometimes so more work in the selection of the suggested peers might be needed.

Open TODOs for this PR:

• average out ranging results if same AP was ranged multiple times in the last 10 seconds to make the position more stable
• Pick random suggested peers instead of the first ones in the list so that the other ones also sometimes get ranged instead of only the first 10

Since the location is updating a lot more often now it would be really nice if the web UI would animate the location changing instead of just instantly moving the point.
Also in locations where the floor level is not entirely stable (e.g. near the open area in the CCH east entrance with the escalators) it also jumps a lot and it would be nice to smooth that out and only change level if it was consistent for e.g. 10 seconds. That might be fixed with averaging of the ranging values tho.

[jennypaxian]

Consider using clear() instead of reinitializing the whole map

[jennypaxian]

Thanks for implementing this, looks generally fine.
Oversimplifying the imports for util class and wifi.rtt is fine in this case because we use most of the classes.
Consider if you want to clear defined HashMaps instead of redefining them.
There might be a simpler way to chain multiple permission requests, unsure.