Update vcpkg to 2023.07.21

[dpogue]

Also make sure we get (older) working versions of a few dependencies.

Port Version Changes

• curl
  8.1.2 -> 8.2.0

• libjpeg-turbo
  2.1.5.1#1 -> 2.1.5.1#2

• libuuid
  1.0.3#13 -> 1.0.3#14

• openal-soft
  1.23.0#1 -> 1.23.0#2

• openssl
  3.1.1 -> 3.0.8#2
  ⚠️ We're intentionally downgrading here to fix an issue where OpenSSL 3.1.x causes crashes on macOS Apple Silicon (AArch64) in debug mode

• physx
  No change, but version is locked to 4.1.2#6 to prevent upgrading to PhysX 5

[dpogue]

On Windows, we make python3 and cairo dynamic libraries because otherwise we run into issues trying to run the Python interpreter to generate the resource.dat files. On macOS, we definitely need python to be a static library because it will cause codesigning issues, but it's unclear if that will cause issues for resource.dat generation.

[dpogue]

@Hoikas Do we need the -plasma triplets for Windows or is it okay to use overlay triplets and just re-declare x64-windows.cmake and x86-windows.cmake with our modifications?

[Hoikas]

I don't think hiding any of the official triplets (eg x86-windows, x64-osx) is a good idea. I'm not certain that vcpkg allows overlay triplets to mask official triplets in this way. If it does, however, in my mind, the official triplets have a well understood output by the C++ community. Changing that output seems like a gotcha. After all, VCPKG_TARGET_TRIPLET is still a user-configurable option in CMake, we just put our opinion on things to make certain libraries build in the way that we prefer. The official Windows triplets produce perfectly working libraries for us, just not in our preferred linkage. So, I don't see why we should hide something that works perfectly fine.

[dpogue]

It appears (based on how the macOS triplets are working here) that overlay triplets work the same way as overlay ports and mask the official ones.

That said, if we prefer to keep our triplets with a suffix, then I'll figure out how best to do that for the macOS ones as well.