Plugin Finder: Add update notifier plugin

[JonathanFeenstra]

This PR adds an IPluginDiagnose to Plugin Finder: PluginFinderNotifier. It displays notifications on startup if newer versions of your installed plugins are available (that are still supported on the current version of Mod Organizer). Each notification has a guided fix to update to the latest supported version of the plugin by clicking the "Fix" button. Mod Organizer will be restarted after the update.

I decided not to inherit from PluginFinderPlugin because it contains some methods that are specific to IPluginTool (e.g. displayName() and tooltip() which are inherited from SharedPlugin), as well as the isActive() method which is no longer used according to Holt59. I think it would be best to remove those methods from SharedPlugin and maybe create a new SharedPluginTool class that inherits from SharedPlugin.

I have not tested this with Qt 6 yet.

[JonathanFeenstra]

I have added the release notes between the current version and the latest supported version to the notifications:

[Kezyma]

I really like this idea, and I think it's probably worth considering in the future adding an auto-update setting and functionality for that, which could be interesting! Thanks for this, it's really cool!

In terms of inheritance, the idea in general was as follows;

• Modules folder contains all the independent plugin functionality, separate from the MO UI.
• The PluginFinder class acts as a wrapper for all of the modules.
• SharedPlugin contains all required plugin fields with some default value.
• PluginFinderPlugin overwrites SharedPlugin with settings and version info to share across each 'pluigin group'
• Each PluginFinderPluginXXXX contains just the UI elements and a few required overwrites.

It's not been followed perfectly, but I'd like to try and maintain this structure, even if just for consistency across the repo, but I'm open to the idea of having separate SharedPluginTool/SharedPluginMapping/SharedPluginDiagnose classes, leaving the base plugins inheriting SharedPlugin and having each implementation inherit both the base plugin and any of the new classes.

At some point I want to write an overall 'toolkit' plugin containing all of these, with some extra dynamic stuff to detect if they're already installed and do some other things with them, and I think the base plugin classes are going to become quite important when I do that!

In terms of functionality, I've only skimmed through it quickly, but one thing that I think would be useful is a setting to enable/disable update warning to unsupported versions that might still work, since I'm still hosting most of the manifests for plugins on PF, a lot of the plugins can and should be updated, even though they aren't marked as supported. Obviously the update warning will need to let them know that it's a potentially non-working update, but I think it would be useful!

In terms of support for Qt with the new MO, I wouldn't worry too much, I'm going to go through and do a mass rewrite and add support for it before the next major release, I've just been too busy to get to it lately.

[JonathanFeenstra]

An auto-update setting should be easy to implement, but it would still require a restart. Should the updates be installed immediately on startup followed by an automatic restart? Or should there be a notification informing the user that the updates will take effect as soon as they manually restart the program?

I have changed the plugin to inherit from PluginFinderPlugin for consistency. I still recommend splitting up SharedPlugin into subclasses for each plugin type, to avoid inheriting unnecessary fields.

A setting to update to unsupported versions is possible, but it would require changing the installPlugin method to specify a version instead of always installing the latest supported version.

[Kezyma]

Sorry, I was sure I'd already merged this in, but apparently, I had completely forgotten! Merged now!