Build both x86_64 and arm64 macOS DMG's

[yuzawa-san]

fixes #1104

• i tried doing the conda version, but found that the qt in there does not bundle properly and was bundling the libraries twice. i may dig into it further later, but this still uses the brew installation methodology
• there are a few gotchas:
• the macos-13 GH runner is x86_64 only in the free tier and the macos-14 GH runner is arm64 only in the free tier, so technically the two produced artifacts have different OS baselines. both brew and conda do not produce universal2 binaries and seem to pin to the OS baselines, so not much i think we could do to get out of this. when we move to macos-14 baseline in the future (since one day macos-13 will be deprecated like macos-12 just was), we will only have an arm64 CI/build environment. this would normally bother me, but given apple has not made an intel laptop since 2019 and they are a few years away from dropping support on macos-13, it should probably work for most people.
• soapyremote is in the main brew repository now. pothos has SoapyPlutoSDR but the dependencies libad9361 and libiio are not up to date. ideally we could eventually move back to the pothos version.
• homebrew moved the prefix (on arm64) from /usr/local to /opt/homebrew which was annoying to support.
• macos-13 still has weirdness with the permissions on /usr/local so more sudo is needed.
• build Release versions using cmake
• remove CFBundleGetInfoString since its deprecated and the "get info" in the Finder uses the version string now
• upgrade CI to use "macos-latest" which is currently macos-14 but will eventually be macos-15.
• i found the quirks in the bundle script around broti, png, sharpuv, freetype were not needed since the libraries appeared to be properly relocated. i could not find any history around why those carveouts existed.
• if i had to guess i broke something in this, it would be around soapyplutosdr or something soapy
• my test build https://github.com/yuzawa-san/gqrx/actions/runs/11431458195
• i QA'd on my own x86_64 sonoma mac and found it worked. i had a friend try to QA on their arm64 sequoia mac but the system integrity mode choked on the unsigned artifact. so i'll open this PR and they the signed one built here. once i validate that with my friend's computer i'll take this out of draft mode.

[yuzawa-san]

@argilo can you please manually rerun the build job on this branch. https://github.com/gqrx-sdr/gqrx/actions/runs/11449528989 it needs to be re-ran by an owner to ensure the secrets for the codesigning make their way into the build artifacts https://stackoverflow.com/questions/73866908/github-actions-main-repository-secret-not-picked-up-from-pull-request-build

[argilo]

Instead of these changes, we could probably just replace the start of Homebrew paths with $(brew --prefix).

[argilo]

This run will hopefully produce signed binaries: https://github.com/gqrx-sdr/gqrx/actions/runs/11736275097

[yuzawa-san]

i was able to have my friend @dangoldin load the ARM64 version on his m3 sequoia mac successfully so i'm taking this out of draft. i also updated the the script to use the brew path as you suggested.

[argilo]

soapyremote is in the main brew repository now. pothos has SoapyPlutoSDR but the dependencies libad9361 and libiio are not up to date. ideally we could eventually move back to the pothos version.

I think I'd rather use the main brew repository. The only reason I didn't is that it didn't have soapyremote at the time.

i found the quirks in the bundle script around broti, png, sharpuv, freetype were not needed since the libraries appeared to be properly relocated. i could not find any history around why those carveouts existed.

macdeployqt did not sign these libraries, so I had to do that manually.