Update to macOS14 runner image

[diceroll123]

Summary

Updates Github Actions macOS runner images to use macOS 13, since runners using 12 will be unavailable on/around December 3rd of this year.

Closes #13231

For more info, see that issue, as well as actions/runner-images#10721. There will be a 10-hour brownout on each Monday in November.

Test Plan

I did not. 😎 (until after the checks passed)

[MichaReiser]

Thanks for this PR and making us aware of the runner deprecation.

We intentionally downgraded the macOS runner in the past because using newer macOS versions resulted in binaries that are incompatible with macOS 11 (#11146, #9834). However, that means that we'll loose macOS 11 support, unless we find another way to cross compile binaries to macOS11.

[MichaReiser]

I did some research and my general reading is that macOS only supports building for the same or newer versions but there doesn't seem to be a way to build for older macOS versions. That means, this PR drops support for macOS12 unless we find another way of running the release job in a macOs12 image.

I found some references of MACOSX_DEPLOYMENT_TARGET but it's unclear to me if that would have any effect, considering that the macOS13 image doesn't have the the macOS12 SDK installed.

[MichaReiser]

Okay, good news. I think I narrowed down why Ruff 0.2 was crashing and we should be fine to just upgrade to the macos 14 runners.

I compared the dynamically linked libraries and they're mostly unchanged (ignoring versions)

ruff 0.2
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2202.0.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)

ruff 0.6.9
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2503.1.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2)

I also compared the dynamically linked symbols and they are almost identical: https://www.diffchecker.com/x9Nond5g/

That's why I went back to analysing the ruff 0.2 crash stack frame and I stumbled across realm/realm-swift#8369 where one user suggests that this is an XCode bug that was fixed in 15.1

Fixed: Binaries using symbols with a weak definition crash at runtime on iOS 14/macOS 12 or older. This impacts primarily C++ projects due to their extensive use of weak symbols. (114813650) (FB13097713)

[MichaReiser]

I'll upgrade the runner to macOS 14 to get faster compile times.

[MichaReiser]

I tested that the binary built on macos 14 runs on a mac 10.15. I built the binary using the CI job in #13785

[MichaReiser]

I downloaded the macos x86-64 binary and verified that it works on macos 10.15