Also compare against existing content lists in a more forgiving way.
The first improvement makes it possible to use relative paths in openmw.cfg without the launcher canonicalising them.
This was really annoying if you used a relative path on purpose.
It also stops the launcher converting all paths to Qt's convention, where forward slashes are used on Windows even though they're not native.
The engine doesn't care, so you could always put either in the config file, but the launcher wouldn't stand for that, and would make them match.
To make this work, we need to store a path's originalRepresentation in the content list, compare paths loaded from openmw.cfg based on their originalRepresentation, and convert paths from originalRepresentation to absolute value when loading them from a content list.
The second improvement means that paths that are equivalent, but expressed differently (e.g. mismatched case on Windows, mismatched separators on Windows, or mild differences like unnecessary `./`es and doubled separators) don't trigger the creation of a new effectively-identical content list.
To make this work, we had to switch the comparison to lexicaly normalise the path first.
It could only be lexical normalisation as originalRepresentation might be absolute, relative, or absolute-but-based-on-a-path-slug, and we didn't want slugs to break things or relative paths to count as equivalent to absolute ones that refer to the same file.
The comparison is case-insensitive on Windows, and case-sensitive elsewhere.
This isn't strictly right, as you can have case-sensitive things mounted on Windows or tell a Linux directory to be case-insensitive, but we can't tell when that might happen based on a lexical path as it depends on real directory properties (and might differ for different parts of the path, which is too much hassle to support).
Previously, if fed bad data, or a content list predated a BSA being moved to a non-user config file, or possibly in other situations (but not any of the obvious ones as those had other guards), the `selectedArchives` list could be longer than the number of archives available due to duplicate entries.
This ensures they're handled like entries specifying no-longer-present archives, and just skips the duplicates.
The same would happen elsewhere in similar situations, but those code paths aren't always taken.
The Windows global config path is really really dumb and the whole concept of having a global path on an OS where it's so easy to have different incompatible versions installed side-by-side (instead of a single canonical OS-wide OpenMW install from the system package manager) is really dumb, too.
We've therefore only used local `openmw.cfg`s on Windows for a very long time.
However, it appears that we were installing the global `openmw.cfg` template instead of the local template.
That's wrong and we shouldn't do it, so I've stopped it.
I've left the separate `openmw.cfg` and `openmw.cfg.install` in the build directory as that makes doing development for portable installs with the same build system as doing the development for the installer easier.
