This makes attribute_value and lexical_cast use the "new" to/from_chars api.
Its main advantages are:
- It's guaranteed to be locale independent, hopefully fixing all cases of #3945 and similar
- It fixes some cases config serialization, in particular the test
```
cfg["x"] = "9.87654321";
BOOST_CHECK_EQUAL(cfg["x"], 9.87654321);
```
- Previously the lexical_cast implementation used exception
handling for invalid formats (catching std::invalid_argument)
which made noise during debugging (and is also slower if it
is not optimized out).
- It's faster
So far afaik the only compiler which has a complete and proper to/from_chars implementation is msvc, gccs implementation of from_chars sometimes uses strtod under the hood and clang simply hasn't implemented from_chars for floating point numbers yet at all (actually the upcomig clang 20 will have it). Luckily for us, there is now also boost::charconv that can be used. So this raises to minimum build requirement to have at least one of:
- msvc 2019 update 5
- gcc 11
- clang 14 (i have added a fallback implementation of from_chars for this case, that doesn't support all of its features, and is probably certainly not as fast as the boost version, but supports the features that we use from it)
- boost 1.85
Since in particular the gcc implementation isn't that good (at least it on gcc11), boost charconv is the preferred implementation that is used if available.
This also removes a strange overload for
pointers to integers in lexical_cast while changing lexical_cast to use the new api.
selected schedule will write to utils/schedule.cfg on scenario save
HOTKEY_EDITOR_CUSTOM_TODS is disabled unless user loads scenario
custom_tod:Preview button and associated callback added.
editor:translatable attributes now written with leading underscore
editor:support for multiple custom time schedules
This additionally:
* Makes all copyright notices identical aside from the starting year for Wesnoth-specific source files. Files not included: mariadbpp, lua, spirit po, xbrz, and bcrypt (crypt_blowfish).
* Removes all attribution from the files, since the vast majority of them are outdated or seemingly just outright incorrect. For example, I would guess that Dave is no longer the sole author of the majority of Wesnoth's current code.
In general I think it's best to use std implementations unless there's a functional or performance reason not to, but also in a few cases this also allows removing the include of lexical_cast.hpp.
Apparently, even on Boost 1.73 without Boost placeholders specialized as is_placeholder, they were somehow
getting used in the global namespace. Would explain all the "Boost placeholders in the global namespace is
deprecated" warnings I was getting after 23d1db043f9f8266c77c6270ed4ef3eafbc0cf67.
When testing with BOOST_BIND_NO_PLACEHOLDERS, even though I had `using namespace std::placeholders` in utils/functional.hpp,
compilation still failed in places. This confirms even more that Boost global placeholders were being used. Honestly,
it was simplest just to specify std::placeholders for everything. This also means we can remove the hack in utils/functional.hpp
designed to allow Boost placeholders to work with `std::bind`.
this has 2 advantages:
1) we can now forwaed declare the class config_attribute_value without
including config.hpp
2) the config.?pp files are a little easier to read.
