* Add a Wesnoth natvis file
The change to t_string is just to make the textdomain map visible to the debugger, since it can't see variables with static linkage.
* Update tstring.hpp
* Update tstring.cpp
The gcc-9 shipped with the Scout runtime forces the use of -static-libstdc++ which is what allows this to work. However, LTO is not yet able to be enabled since as of right now it simply crashes immediately with `free(): invalid pointer`.
NOTE: This does not do any validation of the existing documentation for whether it's correct or complete. That would be the job of someone who actually knows the code being documented. This is simply a format conversion to have everything now use the doxygen format.
This is a "it's known to be broken, so let's rip it out and put in a minimal
replacement" change. Updated raw pointers to smart pointers just because,
updated the docs a bit, and ended up with a big change.
Fixes the most visible part of #5194, where Chinese needed DroidSansFallbackFull
to be loaded before DroidSansJapanese. The removed code in
`char_block_map::insert` and `char_block_map::compress` had a bug that
triggered when one font had a contiguous range of codepoints that was a
superset of several ranges in another font - this meant it treated the first
font containing U+4E00 as having the whole CJK Unified Ideographs block.
Remove the now-unused font codepoints WML. There is no schema change for this,
it seems the data/hardwired/fonts.cfg file isn't checked by the validation.
Optimise calling set_font_list with the same list (but possibly reordered), by
reusing the already-loaded fonts.
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).
Loonycyborg already uses these tools with Python 3.
The python launcher tool for Windows has magic handling for some shebang lines,
however `#!/bin/env python` isn't recognised without the `/usr`. Had the `/usr`
been included with the old code then these scripts would likely have been run
with Python 2.
https://docs.python.org/dev/using/windows.html#shebang-lines
The reasons being:
* It's been unmaintained for several years now, so any bugs that might be reported against it will almost certainly not be fixed.
* Having been unmaintained for so long, even if someone wanted to create a custom Wesnoth IDE plugin, it's unlikely this would be a good foundation to continue with anymore.
* There are at this point better alternatives that people are actually using and maintaining (such as the VSCode plugin).
* Having this be present can give the impression that this IDE plugin is something UMC authors should still be using, which I think makes it actively harmful. Case in point, the current version of this available on SourceForge (2.0.1) was downloaded twice as of the current week; however the most recent version (2.0.2 in the changelog, or 2.0.3 based on some git commits) is not available on SourceForge at all, nobody apparently ever uploading it.
Reasons:
* These projectfiles are still 32-bit, whereas all other builds for all other OSes are now 64-bit.
* Relatedly, these projectfiles are dependent on the libraries kept at the aquileia/external repository.
* VS2019 is still listed as supporting Windows 7, so there is a minimal likelihood of developers not being able to use VS2019.
* The VS2019 projectfiles instead use vcpkg to get the required dependencies, which is easier to setup than the aquileia/external prebuilt libraries.
* It's one less thing that needs to be updated whenever source files are added/moved/removed.
* It's two fewer jobs that Travis needs to run, which means Travis builds will finish more quickly.
