Add CMake builds for server projects

[twostars]

• Implement basic CMake build config (builds on Windows/MSVC)
• Update for Clang (Linux) builds (new warning fixes, any unsupported code)
  • Fixed numerous minor warnings (mostly unreferenced or uninitialized vars/parameters)
  • Added strcpy_safe() to replace strcpy_s() usage which mostly mimics strlcpy -- it's just a little bit nicer, supporting std::string_view.
  • Fix djb2 support.
• Throw away modules (db-modules). Support is technically possible but it's extremely challenging, and will likely be even worse with gcc. It didn't even behave that great in VS, so it's probably for the best it just goes.
• Rename db-modules -> db-models (they're still models but no longer modules).
• Update for gcc (Linux) builds (new warning fixes, any unsupported code)
  • Replaced illegal memcalls (memcpy(this, ...), memset(this, ...) - replaced instances these in the client as well for future-proofing.
  • Brought back regular include guards. gcc choked on at least one case with pure #pragma once; presumably the header being included in different ways. Better to just be safe than sorry and use both.
  • Throw away unions in db-modules we used for arrays (field1, field2, field3 & field[3]). It's not technically allowed by the standard for non-trivial types (std::optional<>), gcc is the only one that's strict about this.
• Restore VS debugger working dir.
• Tidy up generated VS solution to continue grouping projects.
• Add Github workflow for running CMake jobs (Windows - Win32, x64, Linux - gcc, clang).
• Manage & fetch external dependencies through CMake manually (better for seamlessly keeping things up-to-date from a user perspective, but more tedious to keep the submodules and CMake config synced for maintainers).
• Tweaked ByteBuffer to - firstly - build in gcc/clang and additionally just shift implementation (and template) code into a source file to improve compilation times.
• Added sync-submodules project to our regular Visual Studio solutions to ensure submodules are updated correctly on rename/URL change (as was the case with db-modules etc.).
• Remove cmake branch from build_cmake_server.yml before merge (it's kept for testing)

Prerequisites

1. Ensure Git is installed and git.exe is in your system path. If you can open up a console and type git --version successfully, then it's installed and working.

2. ODBC headers need to be installed. For this, nanodbc requires either unixODBC or iODBC (the latter is untested).
   On Debian-based distros (like Ubuntu, Linux Mint), you can obtain unixODBC like:

sudo apt install unixodbc-dev

For connecting to ODBC, you can grab Microsoft's ODBC drivers - https://gist.github.com/hunzo/9c9ce328abc376db1b97a93d1ab38a07
You'll need a MSSQL instance as well; there's a Docker container for it under docker/.

Build steps

It's basic CMake, there's nothing really nonstandard about it.

Generate project files

From the repo's root directory, run the following to configure it:

Linux:

~/KnightOnline$ cmake -S . \
  -B build \
  -DCMAKE_BUILD_TYPE=Debug

Expected build types are Debug, Release, RelWithDebInfo, MinSizeRel (standard CMake build types).
Note that it defaults to Debug.

On Windows you don't need to supply a build type as the solution generated will be for all types (on your default architecture, which is probably x64 -- which you can override with -A Win32):

~/KnightOnline$ cmake -S . -B build

That will configure it, generating all project files it needs for you to build it.

Build project

If you're on Windows, you can now just load up build/OpenKO.slnx in Visual Studio and work with that as-is.
Alternatively, or if you're on Linux, you can just continue to build it with CMake directly:

~/KnightOnline$ cmake --build build

On Windows you should supply the exact build config you want to compile (so assuming your OS architecture is x64 and you didn't override it at config time, this will compile the "Debug x64" build).

~/KnightOnline$ cmake --build build --config Debug

It should build and output its binaries to build/bin.

Ensure you run the server with its working directory set to the program's directory or things may not behave correctly; it'll still (for now, at least) look for the MAP and QUESTS directories a directory above it (so build/bin/Release/AIServer.exe looks for MAP at build/bin/MAP).

If you're running it from VS, this will be the debugger default, so it should just run correctly.

These directories (MAP, QUESTS) are also copied into build/bin/ from Server/bin/. Be sure that if you're changing them, you change the original - when you build the server they will get copied back over the top.

Resolves #644

[twostars]

As of right now, this PR feels pretty complete.

With modern clang & gcc support, our servers now support running on operating systems other than Windows (tested specifically on Linux - Ubuntu & Arch distros, but it should hopefully support things like macOS out of the box as well).

CMake makes it fairly straightforward to build; we don't really do anything non-standard here, so it's just your basic 2 step configure & build process.

As far as requirements goes, there are only 2 external dependencies:

1. git (which the user most likely used to fetch this in the first place)
2. ODBC headers (on Windows the user will have these already). nanodbc explicitly says it supports "either unixODBC or iODBC". Tested specifically only with unixODBC's headers, but we don't do anything with ODBC ourselves so iODBC should also be fine.

All other dependencies (asio, boost, ftxui, etc, etc) are fetched automatically through CMake & git. We don't use the repo's submodules in case the user downloaded the source tree directly.

Of course, this purely supports the server projects only. A lot more work needs to be done in future for native cross-platform support of the client (... not to mention the tools).

As such, the preferred means of development is still through the regular VS project files, where you can build the client & tools as well. However, it does make things a bit easier for devs who aren't using Windows as their main OS.

I've gone back over the PR, fixed/tweaked anything that looked out of place, so this should be tested & reviewed and then I'm happy to merge it (some repos will need to have their branches merged but for building via CMake it won't be an issue since it's all tied via tags - that can be done after this has been merged).