Support macOS bundling for binary distribution

[vit9696]

Polished macOS compilation to properly generate an app file that can be distributed in binary form. Also fixed broken style support and freezing error messages.

While macOS binaries are not very decent, I believe they can be uploaded to the website for better tracking. Could anybody create another PR by zipping rpcs3.app in build/bin and uploading it where necessary?

Note: it appears that the CI failed to pull some environment data on Linux, and the build needs to be restarted to pass.

[hcorion]

While macOS binaries are not very decent, I believe they can be uploaded to the website for better tracking.

No point while the issues mentioned in #5361 are still prevalent, it would just be wasting server space.

[vit9696]

While macOS binaries are not very decent, I believe they can be uploaded to the website for better tracking.

No point while the issues mentioned in #5361 are still prevalent, it would just be wasting server space.

The disk space is provided by github, so I am not positive it is to be taken into account. Despite the issues (yes, I am fully aware about them), we will be able to track that the binaries run at the very least, which I believe is fairly important.

[hcorion]

I've talked with Ani (one of the admins) and he said he's okay with publishing binaries to GitHub, we're just waiting on Nekotekina to create RPCS3/rpcs3-binaries-mac

[vit9696]

Right, in fact there is one more issue. I wanted to address it in the beginning, but unfortunately failed to implement. I believe MoltenVK, despite not working as of now, is no less mature than gfx portability at the very least, and wanted to support them both.

My original idea is to weak link (-weak_library) to either but not include the file. Later on I dynamically loaded (dlopen) one of the libraries to solve the symbols. This works just fine in flat namespace mode (all symbols belong to global namespace), but at present Apple uses two-level namespace (each symbol belongs to some library namespace), which obviosly fails. I tried doing the binding myself, yet it did not work properly (I could start rpcs3 but it would crash later on null pointer exec). I believe this solution may be fixed to work, yet it remains very hacky and not reliable.

For this reason, the way to select the Vulkan implementation is fairly open. We could always patch/symlink the vulkan library within rpcs3.app itself, but it will break codesigning if it is considered.

[vit9696]

Rebased the branch with latest master.

@Nekotekina, I believe we should merge this even if we postpone the binary distribution for macOS. The changes contain several platform-specific improvements and I see no reason not to have them.

Currently nothing prevents us from uploading binary files for macOS, yet it can (should) be a separate pull request.