Additionally, most inclusions of subprojects are unnecessary in my opinion (But I am admittedly pretty biased since I'm not a big fan of submodules :D ).
Except for wswrap and apclientpp, all build dependencies are very common C++ dependencies that are available through most generic C++ dependencie solution.
In my opinion, vcpkg would be a good way to handle them.
Vcpkg was made for your build system, Visual Studio, but is also compatible with most other build systems.
It is pretty easy to handle and takes care of nearly all headaches that build dependency stuff can cause.
I'm currently doing a pretty major refactor of this client and most of the current changes are probably not of interest to you since they only concern porting the build process to cmake and changing the runtime deps to mingw-64 instead of Windows, but I made a branch where I cherry-picked the parts concerning the dependency handling with vcpkg.
You would then have to adjust the VS Project to use vcpkg and maybe change some include directives (I can't make any promises that there wont be other problems, I never used VS, but considering vcpkg is made by Microsoft for VS, it should work relatively smoothly).
I'll make a pull request for that branch, but feel free to just close that request again if you don't want to use vcpkg.
Build dependencies are currently handled inconsistently. Most are included as a submodule (minhook, asio, wswrap, websocketpp and apclientpp) but some are simple hard copies (valijson, nlohmann and openSSL is even hard copied twice https://github.com/Marechal-L/Dark-Souls-III-Archipelago-client/tree/main/archipelago-client/dep/openssl and https://github.com/Marechal-L/Dark-Souls-III-Archipelago-client/tree/main/archipelago-client/subprojects/openssl). Hard copies are always a bit difficult in terms of licences, bloat up project size and make versioning and updating harder. In my opinion, they should be removed.
Additionally, most inclusions of subprojects are unnecessary in my opinion (But I am admittedly pretty biased since I'm not a big fan of submodules :D ). Except for wswrap and apclientpp, all build dependencies are very common C++ dependencies that are available through most generic C++ dependencie solution. In my opinion, vcpkg would be a good way to handle them. Vcpkg was made for your build system, Visual Studio, but is also compatible with most other build systems. It is pretty easy to handle and takes care of nearly all headaches that build dependency stuff can cause.
I'm currently doing a pretty major refactor of this client and most of the current changes are probably not of interest to you since they only concern porting the build process to cmake and changing the runtime deps to mingw-64 instead of Windows, but I made a branch where I cherry-picked the parts concerning the dependency handling with vcpkg. You would then have to adjust the VS Project to use vcpkg and maybe change some include directives (I can't make any promises that there wont be other problems, I never used VS, but considering vcpkg is made by Microsoft for VS, it should work relatively smoothly). I'll make a pull request for that branch, but feel free to just close that request again if you don't want to use vcpkg.