McuSupportPlugin: improve separation-of-concerns

McuSupport Plugin

Some classes have been growing over time, adding functionality in quick patches, becoming responsible of several unrelated tasks at once. The task is to split them into smaller classes that have a single responsibility each, improving separation-of-concerns within the plugin structure.

• McuSupportOptions

This class is currently managing the plugin options, holding data used to construct kits (through an instance of McuSdkRepository), construct kits, manage/filter lists of kits, update kits, check kits on start, and provide some information for building the ui. Possibly even more.

In addition to that mcusupportoptions.h and mcusupportoptions.cpp contain implementations of other classes (related to packages and targets, also kit aspects), that should go into their own files.

And there are some convenience functions in there that should exist in their own class, even if it's private and they'd be pure functional static methods. Something like "McuSupportUtils" or so.

• McuPackage

What a "package" is in this context has become blurry. It might hold a path to a 3rd party tool, flags about how to deal with this path, distinctions between "toolkit", "sdk" and other concepts; there is some functionality for loading/saving and displaying; tracking versions, tracking dependencies, etc.

• McuTarget

Not to be confused with a "Cmake Target". It's the container of information that is used for building a Kit. It holds a list of Packages, but there is also a 'global' list of Packages in the Repository. Maybe a more fitting name could be something like "McuKitPrototype".

• McuSupportOptionsWidget, McuSupportOptionsPage, McuSupportPlugin

These seem mostly fine in their current state, but we still should make sure that SOC is properly maintained.

• McuSupport::Internal::Sdk

This one is a namespace instead of a class. It's a big container of private functions and classes that should be sorted out a bit too.  There's functionality for parsing json, functionality for creating "packages", functionality for keeping track of versioning, etc.