Release portable builds

[ThreeDeeJay]

Just an update for the GitHub Actions CI workflow to (in addition to artifacts already being uploaded to the workflow page) release Windows 32 and 64-bit artifacts in a portable package (soft_oal.dll renamed to OpenAL32.dll with an optional, separate package pre-configured for HRTF, and documentation) for simple drag and drop local replacement for specific games/apps to make it easier for users who are not familiar with copying files to system folders, ensure OpenAL Soft is used instead of other libraries and avoid issues with the router (e.g. currently on my machine, when using the latest router and driver DLLs, the EFXShow process hangs before starting even though renaming soft_oal.dll to replace the OpenAL32.dll router works, both in the system folder and locally)

I pushed the HRTF config to configs/HRTF/alsoft.ini, so perhaps in the future we could also have other pre-made configs like say, 7.1.4/Spatial Audio API, surround sound, crossfeed, super stereo, wave writer, etc., but let me know if it'd be better to use a different location.

My only concern is the issues mentioned here when not using the router:

DO NOT rename the soft_oal.dll files and use them as a substitute OpenAL32 file when doing steps 4 and 5. The method provided above is bound to run into far less problems by using a method similar to the way in which the original OpenAL executed it's dlls, alongside allowing for newer extensions.

Even though the official, stable release readme is much more lenient:

If you do not wish to use the router, then rename soft_oal.dll to OpenAL32.dll
(note: even the 64-bit DLL should be named OpenAL32.dll). Just be aware this
will prevent other system-installed OpenAL implementations from working.

So does the router really provide any fixes/improvements compared to using the OpenAL Soft driver library directly?
And if so, would it be possible to load both the router and driver DLL locally, perhaps even forcing OpenAL Soft library?
The router is refusing to work on my end so I can't check.

Anyhow, this should allow downloading the latest builds directly from static, permanent links like:
https://github.com/ThreeDeeJay/openal-soft/releases/tag/latest
https://github.com/ThreeDeeJay/openal-soft/releases/download/latest/OpenALSoft.zip
https://github.com/ThreeDeeJay/openal-soft/releases/download/latest/OpenALSoft+HRTF.zip

Note that apparently new tags like 1.23.1 didn't transfer to my fork when syncing to the main repo, but hopefully it should always use the latest tag that matches the #.#.# format. 🤞👀💦

[mirh]

My only concern is the issues mentioned here when not using the router:

I really don't know why Cammy8580 felt entitled to smartass their way like that.. Anyway, even though that catastrophism isn't remotely justified, this new behaviour doesn't sound legit either.
I mean, until the usual blablabla #757 I do suppose there are a few scenarios that are more likely to work this way.. But I don't know, still? Maybe what annoys me most is people reinventing the wheel after every half decade, and then people years later having to figure out why the old instructions were so oddly different (making this seems like hot voodoo).

So does the router really provide any fixes/improvements compared to using the OpenAL Soft driver library directly?

Obviously not when there really isn't any routing to do whatsoever by now (in the sense that openal-soft is so much smoking everything else out of the water, that there's no point in changing/switching it except perhaps for testing). Actually Rapture3D (last updated a few years ago tops) is still a thing.
Still if not any when you have to hold together both games that shipped their own router and those that didn't (nonchalantly, because at the end of the day there always was just ONE supposed method for things to work) I actually don't even see how this would be easier overall.