Add support for OpenMW

[Ortham]

libloot support for OpenMW was requested in loot/libloot#98.

OpenMW supports .esm and .esp files from Morrowind, but also has its own .omwgame and .omwaddon file extensions for its own plugins, which use the same basic file structure, but might extend the plugin file format with additional record and subrecord types (I couldn't find documentation detailing the differences). If I understand the docs correctly, .omwgame files are equivalent to Morrowind.esm, and all other plugins in a single game install should be .omwaddon files.

esplugin shouldn't need any changes - it doesn't care about file extensions for Morrowind plugins, and not much about file content beyond the basic file structure.

OpenMW handles installing mods differently from Morrowind, supporting multiple data directories. libloadorder already supports that thanks to the MS Store's version of Fallout 4's DLCs, so no change should be needed there.

OpenMW stores load order data differently from Morrowind - the latter has a timestamp-based system, where load order is decided by plugin file timestamps, and plugins are activated by listing them in Morrowind.ini. OpenMW has its own file, at Documents\My Games\OpenMW\openmw.cfg on Windows and at $HOME/.config/openmw/openmw.cfg on Linux. This seems to be an ini file with no section headers. The ini file is encoded in UTF-8 (source). In that ini file:

• data keys hold paths to directories (e.g. Data Files) that hold plugins. They may be double quoted (e.g. data="C:\path\to\data")
• content keys hold active plugin filenames, and are listed in their load order.

The OpenMW launcher is used to manage data paths, which plugins are active, and their load order. It doesn't write any changes to openmw.cfg until the launcher is exited (e.g. by launching OpenMW from it, clicking its Close button, or by using the window's X button in the title bar). It supports multiple content lists, which let you manage different sets of installed mods, load orders, etc. independently. The current content list is what gets written to openmw.cfg when you exit the launcher, I don't know where the others are stored, but it doesn't matter for OpenMW.

There doesn't seem to be an OpenMW folder in %LOCALAPPDATA%.

Other details:

• When multiple data paths contain the same filename, the last path listed in openmw.cfg is used to resolve that filename.
• Inactive plugins are listed by the OpenMW launcher in the order that their data paths are listed, and within the same data path are ordered in ascending case-sensitive lexicographical order. If multiple paths contain the same filename, the first path "wins" for the display order, even though the filename is resolved to the last path.
• When displaying a mix of active and inactive plugins, I think they're sorted starting with all inactive plugins listed as above, followed but all active plugins in the order they're in openmw.cfg, then sorting keeps the relative order of active plugins but sorts everything else according the same logic as above.
• The OpenMW launcher will hoist plugins above their masters, but OpenMW itself will crash with an error saying the masters are missing or out of order.
• The OpenMW launcher will activate any masters of an active plugin, but OpenMW itself will crash with an error saying the masters are missing.
• OpenMW doesn't force master-flagged plugins to load before non-master-flagged plugins.

So:

• Add a new game ID for OpenMW
• Accept .esm, .esp, .omwgame and .omwaddon as plugin file extensions when the game is OpenMW. Don't support ghosting (that may need some rework to disable it for OpenMW)
• Update GameSettings to read data paths from openmw.cfg for OpenMW
• Figure out how active/inactive plugins are interleaved in the OpenMW launcher
• Figure out how to handle .omwscripts files, which do not use the same file format as other plugins but do appear as content entries and in the OpenMW launcher's load order view
• Add a new load order type for OpenMW that reads and writes load order / active plugins data from openmw.cfg
• Check if the ini Rust library I'm using can round-trip openmw.cfg
• Disable hoisting for OpenMW
• Treat all OpenMW plugins as non-masters
• Document that the load order positions of inactive plugins cannot be persisted
• Document that where the launcher automatically hoists and activates dependencies, libloadorder will display what OpenMW itself sees.

[Ortham]

There's a bit of a problem: while I want to mirror how the OpenMW launcher displays the list of active and inactive plugins so that libloadorder shows the same thing as the launcher, I don't want to mirror its automatic adjustments to the load order (i.e. no hoisting or automatic activation of masters), since a user may launch OpenMW with their current load order without going through the launcher. Those two goals are in opposition, so it's worth documenting that there may be differences due to not performing those automatic adjustments.