Instead of having the preferences dialog make a copy of all advanced preference config objects (and sorting them)
every time you invoke it, this adds a new advanced_manager class instantiated once in game_launcher (not sure if
that's the best place for it, though) that parses and handles the options. Allows me to greatly clean up the
preferences dialog code.
This allows using full markup for the license text and making it
independently scrollable without messing up the dialog. It also enables
URL parsing in it.
Instead of creating lots of image::locators and calling a family of
similarly-named preferences functions, this refactor encapsulates that logic
and uses an enum.
The new orb_status files still need adding to the MacOS build.
An assert has been added to `unit_drawer`'s constructor. There are two callers
- the `display` class guards it with an explicit check before constructing
unit_drawer. The `game_display` class doesn't have an explicit check, but it's
clear that other code in that class assumes the teams are already valid (and
would crash if they weren't).
In source_lists/wesnoth, put the new files in alphabetical order.
This (as expected) fails to build on MacOS, just like the previous build.
It also fails to build with Clang on Linux, just like the previous build. That's
caused by src/scripting/push_check.hpp:89's unused parameter 'L', and is
also just like the previous build.
Reasoning being:
* The result_set and other APIs are nicer to use.
* We use mariadb on our server rather than mysql, so this would minimize the chance of any incompatibilities.
* The mysql C++ connector 1.1 isn't compatible with with c++17 (https://stackoverflow.com/q/47284705).
The first run of the 2019 jobs will fail, since that run will be used to build and cache the vcpkg dependencies - there's no way to get enough time to build wesnoth and build the dependencies in a single job.
This also removes the separate WML_tests.cmd scripts from VC14 and VC16, now instead using the same run_wml_tests script as the linux jobs.
There is currently no caching of the Windows jobs, since msbuild unfortunately uses timestamps rather than more complete information like scons/ccache in order to determine if things need to be rebuilt. Since git doesn't preserve any sort of last modified timestamp, the cloned repo into the travis job is always "newer" than the cached compiled output, and therefore wesnoth is always fully rebuilt.
Ideally, assuming this sticks around and gets out of early access from travis, we could then use just travis instead of travis and appveyor.
