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.
Boost::zlib is basically part of Boost::iostreams, and depending on how you configure Boost, it can either be a separate library or get embedded into iostreams.
With the third-party-but-linked-on-Boost's-website package we've been using for years, it's a separate library.
Before https://gitlab.com/OpenMW/openmw/-/merge_requests/4307, we needed to explicitly link with it as CMake wasn't handling transitive dependencies for us.
With vcpkg, it's embedded, and doesn't have its own CMake config, so we couldn't explicitly link with it even if we wanted to.
Now CMake *is* handling transitive dependencies for us, we don't even need to think about this library.
It's all automatic.
Boost::locale, on the other hand, used to be something we used directly (I think for doing UTF-16/UTF-8 conversions when dealing with Windows paths).
However, it isn't anymore, and we just didn't purge it from our CMake when we should have.
It can go.
Resolves https://gitlab.com/OpenMW/openmw/-/issues/8100
Also removes some old crud.
Hopefully the old crud is all:
* Handled automatically by CMake now we're using the modern approach.
* A hack-fix for a problem caused by not using the modern approach.
* Massively outdated so no longer necessary.
If it turns out this makes CI fail, I'll tweak things as necessary.
Changes that might not be wanted include:
* Getting rid of our BOOST_STATIC CMake option. In cases where the CMake config doesn't make the one correct choice from the build environment (i.e. because there's a choice) the CMake config exposes the option already.
However, we were forcing this on for Windows, so that might matter.
It seems to default to static on my machine even though I thought I read something suggesting otherwise, so we'll see how things go with that.
If we eventually put CMake in charge of installing dependency DLLs this will be a moot point as we won't need to care.
* Bumping the minimum version of Boost to 1.70.0, as that's the first with working CMake config.
It's from 2019, so plausibly there are distros too scared to use a library from five years ago as it can't legally drink in the US (although it could in limited quantities with parental supervision in the UK, as long as it's just something inconsequential like a single sip of beer).
Also attempt to make an equivalent warning fire with MSVC, then have to fix other stuff because /WX wasn't working, then back out of enabling the warning because none of the ones I could find disliked the old code.
The package cmake config uses wrong variables for minor and major versions. They
should be collada_dom_VERSION_MINOR and collada_dom_VERSION_MAJOR but they are
COLLADA_DOM_VERSION_MINOR and COLLADA_DOM_VERSION_MAJOR. CMake variables are
case sensitive so used variables are just empty strings. Set them manually as a
workaround.
On Apple Silicon, the changes to linking paths done to "relativise"
paths in App bundles invalidates the code signature, so we need to
recalculate the signatures *after* the path changes have been performed
but before the install package is created. This depends on a new CMake
feature introduced in 3.19.
