Character traits are only standardized for character types of which
std::uint8_t is not. All major C++ implementations happen to define
this specialization but because it is not standard C++ they are
allowed to remove it as LLVM has done by deprecating this specialization
in LLVM 18. It is slated for removal in LLVM 19. To avoid compilation
errors and to get ahead of any deprecation warnings when LLVM 18 ships
we need to define our own std::uint8_t character traits.
SFML 4 will have access to C++20's std::u8string which should let us
remove this code.
This approach uses RAII to manage resources rather than relying on
correctly calling cleanup functions at all places where scope exits.
This also has the benefit of removing a mutex and no longer having
to lock that mutex so many times.
SFML_ROOT can simply point to the directory in which SFML was installed.
This is verified by our install interface tests which do exactly that,
even when SFML is built as a framework. CMake can figure out where
to find the config module if you give it this much information.
sf::RenderWindow still inherits a virtual destructor from a base
class so there's no need to explicitly declare a virtual destructor.
I added a test to ensure this property was not broken.
This is the warning I got when building this locally
ld: warning: ignoring duplicate libraries: 'lib/libsfml-graphics-s-d.a', 'lib/libsfml-system-s-d.a', 'lib/libsfml-window-s-d.a'
The purpose of those was to make it obvious that an action is needed to
update KeyCount or ScancodeCount when adding more enumerators, but we
rarely touch those enumerations so it is not worth adding those
technical names to the public API.
Those values are not valid Key or Scancode values, so it doesn't make
sense for them to have Key or Scancode type.
Moving them out of their enum makes it possible to write exhaustive
switch case statement without having to write a case for those values.
Making them unsigned int allows to use them as array size without having
to do a static_cast.
