Refactoring of game features for better management.

[Holt59]

Global refactoring of game features management

TL;DR; This changes the way game features are specified to ModOrganizer2 to allow any third-party plugin to set/modify game features.

Why?

The main benefit is for features such as ModDataChecker and ModDataContent, e.g., the root-builder plugin might want to consider mod with Root/ as valid, while this is not a default.

I have not implemented it but this makes adding settings for custom valid folder/files or custom contents very easy.

How?

This adds a new abstract interface IGameFeatures that is available through IOrganizer::gameFeatures that exposes various function to register, unregister and access game features.

A game feature is enabled if

1. The plugin that registered the game feature is enabled,
2. The feature has been registered for the currently managed game (a feature can be registered for multiple games or even all games).

A game feature has a priority

• for some game features, this indicates which feature should be chosen (e.g., if there are two GamePlugins feature, the one with the highest priority will be used)
• for other game features (ModDataChecker / ModDataContent), this indicates the order in which the feature are used.

In practice, I don't think the priority will matter much, even for ModDataChecker (MO2 will check feature until one return VALID or FIXABLE), but maybe in the future this will be useful so I implemented it.

Game features registered by game plugins have lowest priority, by choice. I think this makes sense but this could be changed easily.

Details

This refactors a lot of stuff and has wide impacts on existing plugins but that is a choice I made. I could have added the new system alongside the existing one, but after trying, it was annoying to work with and error prone (letting the old system in place means plugins could still access the old features instead of the new ones).

I never liked the way game feature were implemented, they felt out-of-place, with very ugly tricks to handle them (std::any, etc.). With these changes, all feature inherits GameFeature and you cannot register a class for the wrong feature (which was possible before), which makes code less error prone.

The use of std::shared_ptr for handling game features is mostly dictated by the Python proxy plugin.

---

This PR impacts all MO2 plugins (C++ / Python) that use game features, and I made PR for all of them (repository that do not have similar PR are not impacted by these changes).