Add initial {win,linux}-arm64 target support

[JamiKettunen]

This is a modern remake of the previous draft (#170) which couldn't really be rebased mostly due to the platform-specific splits done with the Velopack transition so it turned out to be easier to adapt what already existed based on the latest MacOSBuilder as an example.

So far tested / done:

• Native linux-arm64 deploy (releases/osulazer-linux-arm64.AppImage works as expected)
• Native win-arm64 deploy (releases/osulazer-win-arm64-Setup.exe works as expected + launched osu!.exe confirmed to be Arm64 architecture via Task Manager)
• Cross (x64) linux-arm64 deploy (works as well from linux-x64 as native one from what I can tell)
• Cross (x64) win-arm64 deploy (works as well from win-x64 as native one from what I can tell, but fails on runtime when done from linux-x64 host fwiw, no idea if cross-OS deploy is expected to work in general)
• Include architecture (at least for arm64) also in Windows artifact filenames like RELEASES etc like is already done with Linux/macOS? This was seemingly also mentioned in the previous PR but without further discussion about it

To-do:

• Anticheat {win,linux}-arm64 native builds (out of my control due to being proprietary etc, shouldn't exactly be difficult to pull off with modern tooling available I feel?)

@smoogipoo could you help clarifying the anticheat ARM64 compile situation from #170 (comment) which largely seems to now be the remaining blocker for official {win,linux}-arm64 native releases (potentially also after ppy/osu-framework@12c4009 is in a new -nativelibs tag)?

If GitHub actions are being utilized https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/ and https://github.blog/changelog/2025-04-14-windows-arm64-hosted-runners-now-available-in-public-preview/ should make it trivial. As I previously also mentioned on win-arm64 technically https://learn.microsoft.com/en-us/windows/arm/arm64ec should allow using the x64 native anticheat or other missing bits without native ARM64 builds (yet).

Closes #170.

[JamiKettunen]

While I understand everything non-mobile/Apple ARM64 is extremely low prio this PR should be in a state where it could be merged standalone without breaking x64 (keeping in mind the program would now be interactive without an additional architecture arg just like on macOS) while the anti-cheat/official builds are taken care of whenever someone has time to look at it. This whole thing is on the finish line to being fully online and unfortunately I can't do anything to help much further without straight up joining the dev team itself

[peppy]

I understand your concern and wish to merge this, and we could, but it would be meaningless. This project is used to create official builds, and we can't create those builds until the other components are ready for use, making this quite useless on its own.

It makes more sense for us to hold this in an open status to maintain awareness that other tasks are required to have it work.