Windows/ARM support

[colincornaby]

This PR has been tested on Visual Studio on top of ARM Windows running in VMWare on a MacBook Pro. Requires Python 3.12 - so this PR is being opened post that merge. This change only targets ARM64.

Changes were required:

• We have to take ownership of the PhysX port in since we have to patch it for ARM Windows. I've added the patch files necessary.
• I added the correct stack frame offsets for ARM64.
• I fixed the CPUID tests which were not behaving correctly on ARM.

Note that I did not add NEON acceleration - Plasma will currently fall back to software for matrix operations on ARM.

Also the CairoSVG wheel is not hosted already for Python 3.12 - and I had a lot of trouble getting it to compile locally. For now - I've disabled the CairoSVG dependency on ARM. I think later versions of Python have that wheel precompiled so I think that will be fixed in the future.

[zrax]

Nice! I'll try to find some time to test this on my Snapdragon X laptop soon...

[Hoikas]

Since we are now vendoring the physx port, we should remove it from the overrides in vcpkg.json.

[dpogue]

Build failures look to be caused by https://gitlab.xiph.org/ being down (temporarily, we hope), rather than any of the changes here, but I'd prefer to see green checkmarks before merging this.

It might be worth, as a test once CI is passing, to add a Windows Arm runner to the GitHub workflows and confirm that it builds properly there (and then likely revert that so we don't keep expanding the CI matrix in all directions)

[Hoikas]

I think having internal/external release builds for ARM64 Windows would be fine. I know our build matrix is large, but I don't think it can be helped, unfortunately.

[colincornaby]

I think having internal/external release builds for ARM64 Windows would be fine. I know our build matrix is large, but I don't think it can be helped, unfortunately.

I'm not sure how this fits into the patching system (and didn't make any attempt to address that.) Unfortunately Windows does not seem to support universal binaries.

But at least for now it's handy for doing local debugging on an ARM machine. (I think @dpogue and I are both spending time debugging the Windows client on an ARM Mac.)

[Hoikas]

The correct way to handle arm64 on windows is likely the same as the method used for amd64... Put a suffix on the manifests. I'd use ARM64 for the suffix.

[colincornaby]

The correct way to handle arm64 on windows is likely the same as the method used for amd64... Put a suffix on the manifests. I'd use ARM64 for the suffix.

Do you want me to go ahead and make those changes now?

[Hoikas]

Let's worry about patching in #1782

[Hoikas]

Was there anything else anybody wanted to see here?