[connectivity-service] Extend the connectivity-api for WiFi scanning

[Sturm Flut]

I am currently trying to build a WiFi scanner app for Ubuntu Touch. Since Click apps are confined and have no root rights, all other approaches failed. I hereby propose to expose the needed information and API calls through the connectivity-api.

The minimum amount of information needed is:

- A list of all broadcasting stations (BSS/IBSS) in range

- Broadcast station MAC address

- SSID (may be emtpy)

- Center frequency or channel (the one can be converted into the other)

- Signal strength

- Available authentication and encryption schemes

- Timestamp when the station was last seen

This is basically the same information as encapsulated in an android.net.wifi.ScanResult object on Android.

Optional, but "nice to have" information would be:

- The contents of the "Capability Info" field of the beacon frame.

- Supported data rates, so one can distinguish between 802.11b/g/n/ac networks. This information is encoded in the "Rates" and ""Supported MCS Set" fields of the beacon frame.

- The contents of the "HT Capability Info" field (if present) of the beacon frame.

This optional information is already recorded by the kernel and is e.g. decoded/displayed by a call to `iw dev wlan0 scan`.

Since the network management service has to monitor its surroundings anyways, e.g. to detect and connect to an already known network or to switch to a better access point during movement, the information should be readily available. A single `scanResults()` call returning a list of broadcast station objects should therefore already be enough.

I propose the following additional API features:

- A method to register a callback function which is called after every successful scan. This frees the application from polling the API, may save power and the app can process new information instantly.

- A method to set the scan interval within a pre-defined range. The network management service may decide to adapt its scan interval to the current situation to save power, e.g. a longer interval when not currently connected and a short one when connected. A scanner app may require a short, constant interval.

[Sturm Flut (sturmflut)]

I want to add the following paragraph about security/privacy:

A hostile app may calculate the location of a user from the list of access points in range, and because of the short-range nature of WiFi this location will be quite accurate. I therefore propose that the first call to `scanResults()` triggers a system popup informing the user about possible privacy implications and asking for permission.