GPS: Prepare for New Position Source

[HTRamsey]

Goal here is to eventually support external GPS in PositionManager, which will significantly help with Follow mode (currently can only use internal Android gps)
Tested on a ZED-F9P

• Move RTK handling to its own class
• Prep to support more GPS messages & external GPS
• Cleanup GPS definitions
• Remove Toolbox usage
• CMake Fetch Drivers
• General code quality/cleanup

Edit: Following Moved to Part2 PR

• GPSProvider threading improvements (Don't inherit from QThread)
• Add unit tests
• Make GPS RTK inherit from GPSProvider and have separate regular GPS class?

[DonLakeFlyer]

I'm concerned about removing the concept of accessing/initializing these managers through the toolbox. This removes the two-phase initialization aspect of these objects. This two phase approach was specifically added because there is ordering required for some of the tools. A specific example is that the SettingsManager must be created first and can only be referenced by other tools in the second phase of their initialization. If GPSManager is removed from the toolbox it means there can be a race condition between it and SettingsManager if GPSManager goes after settings in the constructor for it.

If the goal is to remove the toolbox to move to a static instance pattern then the first step needs to be to move SettingsManager to be instance pattern to remove the race condition.

I also wonder about the fact that the toolbar provides a level of readability on the code so you a number of the moving parts available all at once. That said though those moving parts are kinda unrelated so I guess there isn't much value there.

[HTRamsey]

Changing the toolbox part isn't a necessary part of this PR so I can remove that. However, I personally am not a fan of the toolbox paradigm, here are some thoughts:

• Everything has to link to everything because of it. Makes testing isolated components difficult, as tests can fail from any other part of the application. All the if(isRunningUnitTests()) is a consequence of not being able to control which parts of the app are running during the tests. This would also make it much more clear which parts of the code are reliant on other parts.
• Lifetime management. Don't need & shouldn't have the entire app instantiated all the time. Previously, toolbox components weren't actually even cleaned up & deleted at end of app because of incorrect parenting, it is automatic with Q_GLOBAL_STATIC.
• Instantiation order, calling GPSManager::instance() just instantiates GPSManager the first time it is needed, which will in turn instantiate any other instance it needs. Order doesn't matter and init functions are unnecessary. So connections can be made in constructors. This also makes it easier for custom builds to add components without messing with the toolbox.
• There can never be more than one toolbox, so global statics are fine
• Also there's a whole lot of mixed usage of passing around tools through parameters vs calling through qgcApp()->toolbox() and this will help standardize that

[DonLakeFlyer]

All make sense to be a better way to do things. Could you convert everything over to instance based creation and get rid of toolbox in a separate pull?

[HTRamsey]

I could, although that would be a large error prone PR probably. Which is why I was going step by step for each tool