Setup ClangCL PlatformToolset

[kornman00]

This is the initial work to support building with ClangCL under VS2022 (I don't believe VS2019 proper ever had ClangCL support). There are no code changes yet, as I would prefer to supply those in a subsequent PR and not hold up this rudimentary groundwork. E.g., trying to build DebugClangCL will not work right now, as there are clang-compat issues in the code that need to be addressed first.

Aside from ClangCL support, I also consolidated the vcxproj properties (DRY principal and all), use v143 out of the box under VS2022 (although if this doesn't sit right with you, I can remove that change...I was able to run under v143 without issue, on VS2022 17.8.3), and moved the default debugger properties to the vcxproj and removed the committed .user file.

As of this comment, VS2022's clang-cl toolset is based on LLVM 16.0.5. I have not had major issues with this version on a different project which I was updating to C++20 (for constexpr and saner STL features, like string_view, span, etc). FWIW however, there's an actively maintained fork of LLVM that explicitly targets MSVC compatibility: https://github.com/backengineering/llvm-msvc. Although, I've had issues with some of their changes, e.g. NewWorldComingSoon/llvm-msvc-issues#109. That related to unused-function warnings being implicitly silenced without being able to turn them back on. On a large project with lots of legacy code (that is no longer relevant), that is less than ideal.

[richgel999]

Thanks! Will review soon and merge in.

[kornman00]

I've done the work today to get DebugClangCL compiling (haven't yet committed it, since it would update this PR I believe).

Some things of note ahead of time:

• I changed the <LanguageStandard> from the implicit default (stdcpp14) to stdcpp17. Namely, to leverage static_assert without an explicit message. I came across one assert() which could have been statically validated. I could switch it back to stdcpp14 if you prefer, though.
  • For the utils like string_format / vformat, C++20 introduced std::format. If that specific language addition is okay with you, I could evaluate enabling C++20 post-clang_cl and updating formatted prints to std::format. Likewise, with stdcpp17 std::string_view is viable, which could replace some areas where you're having to construct or pass std::string around. Though, I can respect being averse to some of the committee's decisions.
• I had to resave at least two source files as UTF8 (with BOM) as Clang saw sequences like u8"ValléeMagonia" as containing UTF16 characters and called fowl on the character sequence.
• There are currently unused functions (-Wunused-functions) in various places. E.g., ufojson.cpp's detect_bad_urls(). I've marked these up with the [[maybe_unused]] attribute to silence these warnings for now, as I expect these are probably functions written in some prototype project before being committed to github, or are being used in uncommitted changes on your end.
• There are some signed/unsigned and implicit casts warnings across the codebase which I'm trying to address. Ideally, to get to a place where <TreatWarningAsError> can be enabled.
• I'm noticing some generated files in bin\ after I run are appearing as modified to use CRLF while in the repo they are apparently LF...not sure if that's something goofy on my end, e.g. maybe a misconfigured git setting to deal with crlf quirks.

Please let me know if anything mentioned does not jive with your expectations of contributions. Thanks!