Add Options based configuration into CLI and Examples for BlueGiga

[tthiery]

• Create a construction-injectable Options object for BlueGiga
• Refactor the CLI service provider builder process to better incorporate the command line (and maybe a json file ... so user can spare the arguments). Use Microsoft.Extensions.Configuration.CommandLine features maybe.

BlueGiga in focus because currently the only one needing configuration

See details in #154

[rickjansen-dev]

An options object would be useful for BlueZ implementation too. Mainly to specify a specific bluetooth adapter (eg hci0) instead of simply using the first available one. Kind of optional since multiple available bluetooth adapters seems like a bit of a edge case.

Maybe best to open a separate issue to complete if this one is done?

[tthiery]

Let us focus on finishing bluez first. We see which delivery beat which and then we adjust :)

[dkurok]

I've tested today with BlueGiga on a RaspberryPi with the actual Master-branch - works like a charme!
The BleuGiga-adapter gets recognized on the Pi without any additional installation and is just a SerialPort:

./SharpBrick.PoweredUp.Examples --usebluegiga /dev/ttyACM0

..and it works. Also with two Hubs in parallel (ExampleTwoHubsMotorControl) 😄
Surley I had to remove the dependency on the SharpBrick.PoweredUp.WinRT from SharpBrick.PoweredUp.Examples because WinRT cannot build for linux-arm target. Also instead of net5.0-windows10.0.19041.0 just only use net5.0 in the TargetFramework
for Examples and BleuGigaBLE. And some small changes in BaseExample.cs(comment line 97 which is calling AddWinRTBluetooth() and Program.cs (just for making sure the options are given over to InitHostandDiscoveryasync(); line 82 instead of 80)
publish for Raspberry Pi:

cd GitHub\sharpbrick\powered-up\examples\SharpBrick.PoweredUp.Examples
dotnet publish -r linux-arm -o bin\\linux-arm\\publish --no-self-contained

Why do I mention it here?
Because we need to think about how to separte the different BLE-implementations into different independent Nuget-packages later, so it gets easy to build for differnt platforms. With Bluez-implementation in near future it will be an additional candidat which probably will not compile for windows-target.
So it should be in mind also here...

[tthiery]

Oh that is nice. Create a PR updating the README

second: Yes, I agree. We need to decouple the dependency to the bluetooth stacks in the tools etc. There is a "plugin"-like concept called AssemblyLoadContext which can load assemblies at runtime. With a small generic helper, all the CLI, Examples, TestScript Runner can dynamically load an adapter. The only thing I am not sure is, does it work with the -windows target when called from a command line part. To be tested. In doubt, we can multi-target.

[dkurok]

I've tested on a Raspberry Pi 4. I will do another test on a Raspi 3 and also on an Ubuntu 20.0 LTS (PC-based). As soon as I have finished these tests, I will update the README. Shall I go for an own file BlueGigaReadme.md for bringing all the information for BlueGiga centralized or put it into the big README? It's more a question of wanted style from your side.

[tthiery]

That is indeed a good idea. Put it somewhere reasonable in the docs folder and link it from the main readme. That declutters the project start page.