game/mods/mod_manager: Add support for Launchpad's custom mod statuses.

[DaloLorn]

Some of the behaviors of the Launchpad's mod manager pane require new mod statuses to be present for disambiguation. Without them (or an external config file, which feels a little clunky), the Launchpad can't correctly process these scenarios:

• A mod is implicitly enabled by a deriving mod. (Implied)
• A mod is enabled, but is also implicitly enabled by a deriving mod. (EnabledDependency? Dunno, still figuring out the terminology here... and possibly even how the Launchpad should handle it in the first place.)

The Launchpad can safely write the relevant values to mods.txt. Per lines 349-350, any value other than "Forced" and "Enabled" is interpreted as "Disabled". However, any scripts calling saveState() at line 381 via the saveModState() global function (used by the ingame mod menu and the mod editor) will then overwrite those values with an actual "Disabled" value, which is not ideal.

This is a low-priority tweak, as it should hopefully only affect users who are using both the Launchpad and the ingame mod menu, and users which use the mod editor. Even then, it'll only have an impact in very specific contexts, and will only amount to a QoL inconvenience whenever it affects them at all.

• Add storage for new Implied and EnabledDependency statuses.
• Add proper serialization for those statuses.
• Preferably expose those statuses to the script engine, so that the mod menu can be altered to account for them. (However, we shouldn't yet make any such alterations. We'd need to complete AngelScript compiler: Update to latest version, add support for OpenSR-only scripts. #10 first, for backwards compatibility with builds not featuring these statuses.)

[DaloLorn]

Actually trying to implement this design has left me questioning its merits.

Instead, here's what I'm going with (and will be adjusting the Launchpad to support) whenever it's merged into master:

• Each mod now knows all of its descendants.
  • This might be useful to the UI somehow, but I haven't yet worked out how or if this is the case. At any rate, it's just a set of pointers populated while loading the mod list, so not much overhead.
• Each mod keeps a running count of how many enabled descendants it has, tentatively named requireCount.
• All of this information (plus helper methods to query if any descendants are enabled, and which ones,) is exposed via AngelScript.
  • Still a little fuzzy on the inner workings of C-AS bindings, but I think my current draft makes requireCount mutable in AngelScript, too. Counterintuitively, this might actually work to my advantage: With the way Starflare's mod loader works right now, the whole active mod list is discarded and rebuilt from scratch every time you change it. Consequently, requireCount is also discarded for each mod, so it should be okay to use it as a preview value while the player mucks about with the mod list.
  • The Modpack will of course want to provide wrappers around this functionality. I shouldn't have too much trouble with that.
• This information is not persisted to the filesystem in any way. Instead, the Launchpad will just have to reimplement a few more chunks of mod_manager.cpp. Now that I'm getting more comfortable reading the original C++, that shouldn't be too much trouble.