Implement delay to avoid system scanning throttling

[LouisCAD]

Since API 24 (Android 7.0), only 5 scan starts are allowed for the app in windows of 30 seconds.

This gotcha is among the not well documented parts of Android BLE.

This should be easy to achieve with Flow (relates to #5).

Different scan throttling strategies might be allowed.

• A "cautious" one could ensure all scan starts are spaced by 6 seconds delaying any start happening sooner.
• An eager one could delay the 6th scan of the 30 seconds window.
• A middle ground (possibly configurable) one could allow to be eager, but not too much to avoid delay if the scan starts count exceeds the 30s window limit. Could delay with a growing backoff (linear, exponential, or custom).
• Finally, there could be a strategy to keep the started scans alive after flow cancellation for up to the duration of the 30s window, so if a new scan with the same filter is requested, it can be reused without counting in the scan starts quota.

This will need an instrumented test and/or a test app so we can rest assured all the strategies work as expected with the full range of their allowed parameters.

The reference test advertising device, its software and its config are yet to be determined.
A Raspeberry Pi 3 B running Android Things might be a good choice because of the low price point, and the Android APIs usable from Kotlin.

Last note: It might be interesting to see if we can handle a continuous scan by restarting frequently the scan as it should be easier with Flow (maybe using old BLE API if it works better), for devices that have malfunctioning bluetooth low energy (can often be determined with ease with Wi-Fi enabled).