Switch to C++20

[kring]

The main motivation here is support for the upcoming Unreal Engine 5.5. It uses the GSL library, as cesium-native does, but it's a modified (broken) version of it, so we can't use UE's version in cesium-native. Using our own copy creates conflicts with Unreal's. So one possible solution is to switch to C++20, change all the gsl::span to std::span, and drop the dependency on GSL. This PR is the first step in that.

Some notes:

1. The version of Async++ that we were previously using, via vcpkg, does not work in C++20. A new version that fixes this was only tagged very recently, and is not yet in a tagged vcpkg release. Which means that this branch uses a prerelease vcpkg for the moment. We should probably wait until the next vcpkg release, and then use that, before we merge this. I think it should be really soon.
2. Compiling TestPropertyTableView.cpp for C++20 RelWithDebInfo on Ubuntu 22.04 uses a ton of memory, crashing the GitHub Actions runner. We should be able to fix this by moving away from std::variant, as we've done in Unreal and Unity, now that we're on C++20. But for now I've just added a build step to increase available swap space so that the build can complete successfully.
3. C++20 made the u8string method of std::filesystem::path returning a std::u8string instead of a regular std::string. This is fairly painful because we were already using std::string to represent a UTF-8 string (in C++17 there was no better alternative), and there's apparently no conversion between u8string and string. We should consider whether we should standardize on u8string everywhere, but I'm not sure of the implications. For now I've done the simplest thing: I've added a conversion and called it where we need it.
4. Our generated Spec classes had a private constructor, when it should have been protected. C++17 didn't care (surprisingly!), but C++20 does. C++20 also requires that derived classes explicitly declare a public constructor if they're expected to have one.
5. I reworked how we interface with STB Image Resize, because slamming it in a namespace is a bit dodgy and was creating compiler errors (not sure if it was a result of C++20 or a result of the changed vcpkg version). Now we just mark it static and expose helper functions that can be used to call it from outside the one module where it's defined.

[kring]

I'm marking this ready to review. My only small reservation is that it still uses (by necessity) a pre-release vcpkg repo. I think the new version, including the fix we require, should be out by the end of the month.

[j9liu]

@kring looks good to me! I just had one comment that I wanted to run by you before merging

[j9liu]

Nitpick but, I feel it would be more informative to say toStdString? The input and output are both UTF8, and the only thing really changing is putting it in a std::string wrapper.

Suggested change

	static std::string toStringUtf8(const std::u8string& s);
	static std::string toStdString(const std::u8string& s);

[kring]

I think the Utf8 bit is important. It's true the function doesn't change the UTF8-ness of the string, but that's the key feature to communicate. String was meant to imply std::string, but maybe that's not obvious. How about toStdStringUtf8?

[j9liu]

That's a fair point. I was thinking back to Unreal / Unity contexts where there are multiple string types, so they have functions like ToFString(), toStlString(), etc. But specifying std::string is probably overkill for Native, where C++ std::string is the norm. You can disregard this comment!

[kring]

New release of vcpkg is out, which should let us move off the prerelease one used in this branch. I'll do that today.
https://github.com/microsoft/vcpkg/releases/tag/2024.11.16

[j9liu]

@kring I went ahead and switched us over to 2024.11.16. Looks like I haven't broken CI, so I'll merge now. Thanks! 😄