Add filter options to scanning

This is a feature request for the aioble/low-level bluetooth libraries

The use case is a remote patient monitoring central application that needs to support a large set of personal health devices, a few of which support the BT SIG health device profiles but the vast majority of which are proprietary. The idea is to present to the user only newly discovered devices that the central understands and connect automatically to those the user has already opted to connected to. The users are not tech-savvy and know nothing about Bluetooth.

It would be advantageous (at least for these needs) if the scan results could be filtered. For example, I want to only receive connectable advertisements/scan responses that have one of a list of service UUIDs or whose name contains a certain string or whose manufacturer data contains certain sets of masked byes. IN my case I am looking for these values in the adv and or scan response.

Of course it is possible to do this filtering on the scanResults received at the application level but in a location where there are floods of advertisements coming from all kinds of junk (such as in an apartment building) the library would be able to block the unwanted material at a lower level, and depending upon the platform and BTLE chip, maybe even in hardware. This would increase efficiency.

It would also be convenient to knock off duplicates by address. Of course, that would only work if the scanner is run periodically (say for 12 seconds) and then restarted resetting the duplicate filter, otherwise a device would be permanently blocked once seen.

No files or tests are named. Start by locating the aioble and low-level Bluetooth scanning entry points and reviewing how scan results expose advertisements and scan responses; define the supported filtering inputs and duplicate-by-address behavior before implementation. Done should be demonstrated by coverage for the requested filters and periodic-scan duplicate reset semantics.