Add metadata to download buttons, refactor Platform.php, Os.php

[tresf]

Adds metadata to the download buttons.

- <a class="btn" href="/download/artifact/3040190119">
+ <a class="btn" href="/download/artifact/3040190119" data-arch="Intel" data-os="Windows" data-qualifier="msvc" data-osver="">

... part of an effort to automate PR downloads https://github.com/tresf/lmms.sh

[headquarter8302]

About osver logic. Since on the site we're detecting the compatible OS version using the filename, will it ever be filled for other OSes?

I'd imagine putting a hardcoded check like if "win64" then osver="windows11" wouldn't be suitable as both Windows and Linux builds have very wide compatibility margins, unless we specify both bit-ness and a known minimum compatible version lookup in the Platform logic

[tresf]

About osver logic. Since on the site we're detecting the compatible OS version using the filename, will it ever be filled for other OSes?

I'd imagine putting a hardcoded check like if "win64" then osver="windows11" wouldn't be suitable as both Windows and Linux builds have very wide compatibility margins, unless we specify both bit-ness and a known minimum compatible version lookup in the Platform logic

I've been thinking about this and it might be helpful.... but...

• If we do this for Windows builds, I'd recommend that we mark our existing Windows downloads as windows7 or windowsxp. (IIRC, PortAudio in nightly bumps it from windowsxp to windowsvista due to some win32 APIs expected...) However, detecting -- and thus comparing -- the OS version might have wider implications. Windows lacks a proper SemVer... even if we did, we now would assume the script can run on Vista or Windows 7 (Which brings old PowerShell into the conversation). Furthemore, would the script want to install the old version automagically? This is a lot of tech debt.
• If we do this for Linux builds, it would likely encourage us to provide this information from the CI (e.g. Ubuntu 22.04 runner would be modified to provice this info in the name of the file) so that we never have to maintain this information downstream (e.g. in the website). This would be nice, but it's not necessarily helpful because it's often libs like glibc that break compat so we'd likely be better off documenting that, but then we're spending a lot of resources around detection of that, which comes with more tech debt.
• macOS is pretty straightforward due to it's walled-garden approach, but it's still arguable whether or not we want this info. The only reason I implemented this was so that I could always provide the newer stable release, so this is likely to be phased out completely when 1.3 is released in stable form.

... so I'm OK if we wanted to add this info in, but maintaining it in some "automatic" form might be best done on the lmms/lmms side (perhaps in the CI). Do you agree?