[M1] [regression] Olympus crash from defaulting to wrong architecture

TLDR: After a recent update (the one that upgraded the bundled LOVE binary to 11.4), Olympus seems to crash without any error log on my M1 Mac (similarly tested on a friend's). It seems that the issue is that the OS thinks that Olympus.app works with arm64 even though there are various x86_64 dependencies which I suspect is causing the crash. Telling it to explicitly run as arm64 fixes this locally for me, and modifying `Info.plist` (discussed below) in the azure pipeline seems like it would fix the distributed copy for everyone.

**quick fix for anyone who needs it: Right Click Olympus > Get Info > check the Open Using Rosetta box**

# Setup / Problem

Downloading the latest version of Olympus from [this page](https://everestapi.github.io/), which at the time of writing is [this](https://dev.azure.com/EverestAPI/Olympus/_apis/build/builds/3328/artifacts?artifactName=macos.main&$format=zip) yields `macos.main.zip` which I can unzip to get the `macos.main` folder. Unzipping `macos.main/dist.zip` yields `Olympus.app` as expected. I approved it to the OS security thing so that it'd let me open it.

Opening Olympus.app however cause it to crash instantly, with no logs written to `~/Library/Application\ Support/Olympus` and no crash screen, the app just instantly exits a few milliseconds after opening – it doesnt even create the `~/Library/Application\ Support/Olympus` folder.

(I tried a bunch of little things that haven't had any effect: deleting Olympus from `Application\ Support` to make this a fresh install, deleting Celeste (both from `Application\ Support` and the steam app), uninstalling all system versions of Lua and Love2D to make sure that's not interfering.)

This actually didn't used to be a problem, it runs fine on older Olympus versions and I encountered this when autoupdating my Olympus installation. I tracked down the Olympus version where it started happening by trying all the uploaded build versions I could find by looking through https://dev.azure.com/EverestAPI/Olympus/_apis/build/builds/ . It seems to have happened between these two builds:
* build 3315 (23.05.24.06) works fine from me [build log](https://dev.azure.com/EverestAPI/Olympus/_build/results?buildId=3315&view=results) [download](https://dev.azure.com/EverestAPI/Olympus/_apis/build/builds/3315/artifacts?artifactName=macos.main&$format=zip)
* build 3324 (23.05.25.08) no longer works for me [build log](https://dev.azure.com/EverestAPI/Olympus/_build/results?buildId=3324&view=results) [download](https://dev.azure.com/EverestAPI/Olympus/_apis/build/builds/3324/artifacts?artifactName=macos.main&$format=zip)
* The git diff between these commits is [here](https://github.com/EverestAPI/Olympus/compare/092fc73b...55195502) it seems like the main thing is that LOVE was upgraded to 11.4.

# Whats actually happening

After way too much analyzing, I suspect that in the cases where it's crashing, it's accidentally attempting to execute `./love` in arm64 mode instead of x86_64 mode (since M1 supports both). The `love` binary is a universal2 binary so it supports both, but the dependencies packaged with olympus require x86_64. We can explicitly tell it to use x86_64 when calling `love` and this fixes it.

Proof of concept change showing that this is the issue: replacing `./love --fused olympus.love $@` in the "bundled love" section of `olympus.sh` with `arch -x86_64 ./love --fused olympus.love $@` fixes it.

However really we'd like the whole Olympus.app to know that it should be running as `x86_64` in the first place. Looking at the `Get Info` screen it has an "Open using Rosetta" checkbox option indicating that it thinks that it can be opened with either x86 or arm64 (note that toggling this also fixes the bug, even without the `olympus.sh` change). This is probably because the `Olympus.app/Contents/Info.plist` doesn't explicitly specify the architecture to run with, and it must be noticing that the `love` binary works with either architecture and so it lets you use either and defaults to arm64.

It makes sense that this problem happened when upgrading to LOVE 11.4 since that was when they added apple silicon support and replaced the `love` binary with a universal2 binary that supports either architecture. Olympus just needs x86 specifically because its various other dependencies are compiled for x86. In a separate, painful, unnecessary tangent I locally recompiled the various `.so` files for arm64 and that fixed it. However in practice it's probably way easier to just mark Olympus as x86_64 rather than try to actually compile dependencies for both architectures, so I would probably not recommend that.

# Solution

To specify the right architecture we can use the plist attribute [LSArchitecturePriority](https://developer.apple.com/documentation/bundleresources/information_property_list/lsarchitecturepriority)

Olympus already does some plist manipulating in the azure pipeline here: https://github.com/EverestAPI/Olympus/blob/137371a616a3b3cc7fe416a41cb7713c374f4182/azure-pipelines.yml#L378

So if PRing this in we could probably just add the new plist modifications right after that. In particular we'd add:

```
plutil -insert LSArchitecturePriority -array $PLIST
plutil -insert LSArchitecturePriority -string x86_64 -append $PLIST
```

which tells it that x86_64 is the only valid architecture for this app. After running that locally, Olympus works fine for me and the "Open using Rosetta" option disappears (though you do have to move/copy it somewhere for mac to realize it should remove that option – that shouldnt be needed in the azure pipeline though since it'll take effect when someone freshly downloads the file).

Happy to help out more with debugging this further (here or on celeste discord) and coming up with a PR if people familiar with Olympus are interested. Also happy to potentially help the Olympus devs test other stuff on M1. For reference I have an M1 mac running OS X 12.3.

Thanks Olympus devs for all you do! <3