macOS: Apple Silicon support (interpreter only)

[exverge-0]

Fixes #396(?), supersedes #1211 (I don't own BOTW and haven't been able to reproduce the issue on other games, but this fixes a similar error that only occurred on Apple Silicon)

The re-compiler hasn't been implemented and only the interpreter works. (and there's already an WIP aarch64 recompiler for cemu android, assuming that they plan on merging into this repo)

[Exzap]

I'll be honest, it will probably be a while until we have a decent ARM recompiler that will outperform Rosetta so this seems a bit early. But I generally don't want to stand in the way of adding new target platforms. That said, the changes made here are detrimental for other platforms. Just on a quick glance some obvious issues:

• Putting gx2WriteGatherPipe access behind a mutex is absolutely gonna wreck performance. Better to work with atomic pointers or manually insert memory barriers where needed.
• mmuRange_HIGHMEM is supposed to match Wii U's memory map. I get that there is a 16KB page size restriction but other platforms don't have this so it should be conditional.
• Lots of changes in the h264 decoder, would be nice if you could give an explanation?

[exverge-0]

Lots of changes in the h264 decoder, would be nice if you could give an explanation?

On OSX, C functions are compiled with a leading underscore and the header files define the ASM functions as a normal C function, resulting in functions being called with a leading underscore but defined without one.
Admittedly now I see this could probably be done by just marking them with extern, I'll do that instead This results in the same thing.

Putting gx2WriteGatherPipe access behind a mutex is absolutely gonna wreck performance. Better to work with atomic pointers or manually insert memory barriers where needed.

Makes sense, I'll revert that and try something else

mmuRange_HIGHMEM is supposed to match Wii U's memory map. I get that there is a 16KB page size restriction but other platforms don't have this so it should be conditional.

Ah, I wasn't sure but that's what I somewhat assumed.

[Exzap]

This should iterate each color attachment and when an integer format is used then disable blending only for that specific attachment. Having one color attachment in integer format does not prevent blending for all the non-integer attachments.

[exverge-0]

Having one color attachment in integer format does not prevent blending for all the non-integer attachments.

I see how that could be an issue, however the main issue is that they are disabled, yet for some reason creating the pipeline on MoltenVk results in this error. The only other solution I could think of is to remove the color attachments entirely in InitBlendState if they are integer formats, though I'm not sure how that could be done without massively rewriting the code for what appears to be an issue with MoltenVk.

I originally made it like this since, at least on MK8, only the first color attachment would ever be in integer format, and if it were, the rest followed by empty attachments, though I see that this wouldn't be the case for all games. Other than the potential solution above, I'm not sure how else to deal with this.

[Exzap]

I see. I don't want to chalk this down as a bug in MoltenVk yet because it seems to be too big of an oversight to me. I checked their code and I couldn't really see any logic that would enable blending if we didn't specifically ask for it. But more digging is required to understand this fully.

In the meantime an acceptable temporary workaround would be to disable all blending if ANY of the color attachments are integer format instead of only checking index 0. I also suggest making the workaround apply to MacOS/MoltenVk only.