Introduce an interface to wrap around the bluetooth-library-specific calls

[MoralCode]

This would allow the specific bluetooth library in use to potentially be swapped out and/or made the responsibility of the application, but also may provide more surface for bugs and/or issue reports as people will likely use different bluetooth libraries

Some Bluetooth backends to consider when designing such an interface:

• https://github.com/pauldemarco/flutter_blue
• https://github.com/dotintent/FlutterBleLib (what this lib is already based on)
• https://github.com/PhilipsHue/flutter_reactive_ble

[MoralCode]

Fully abstracting the bluetooth library seems like it may not be especially useful and may increase debugging complexity if clients are allowed to use different bluetooth backends what may have different bugs.

in the future the interaction with the bluetooth library may be beneficial to abstract but for now there doesnt seem to be enough value to justify the additional effort.

#17 already implements a rewrite of the backend so that may provide useful information for how to create an API thats reasonably compatible with any bluetooth backend.

given the current state of flutter bluetooth libraries (TL;DR "not a lot of great, well-maintained options") this ability to swap between them may be something that could help to abstract into another library for other bluetooth projects