Allow configuring audio latency with an env variable

[rszyma]

This allows setting latency below currently unchangeable 20 ms audio device buffer by setting an environment variable OSU_BASS_CONFIG_DEV_PERIOD.

Resolves #6647

Previously there was an attempt at a similar change in #4008, except it tried adding in-game settings. From my understanding it didn't work out because we don't want casual users to have access game-breaking settings. It makes sense.
Environment variable on the other hand is less visible, and usually noobs won't be able to just set it mindlessly and break their game lol.

Tested in osu on Linux + ALSA exclusive mode, per instructions in this comment.
I have not tested on other platforms (sorry! please someone else do)

Before (raw ALSA device):

$ cat /proc/asound/card*/pcm*/sub*/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 441
buffer_size: 882

After (raw ALSA device + OSU_BASS_CONFIG_DEV_PERIOD=2):

$ cat /proc/asound/card*/pcm*/sub*/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 88
buffer_size: 176

Value of 10 (ms for period_size, 20ms for buffer_size) is the default currently for raw ALSA devices output for me on Linux running the latest tachyon release (2026.318.0-tachyon).
I can set as low as 2 on my machine but 1 does chop terribly.
I run RT kernel FWIW. This will vary for on different hardware of course.

Edit: with the lastest commit, by setting OSU_BASS_CONFIG_DEV_PERIOD=-64 I can lower it even more to period_size=64, buffer_size=128.

Edit 2: real measurements here: #6647 (comment)

[rszyma]

It seems like this is primarily useful when NOT routing audio through pipewire. With pipewire it appears that pipewire settings clock.quantum and api.alsa.period-num can control period_size/buffer_size of the pipewire-managed ALSA output

But when selecting a raw ALSA device output in osu settings there seems to be no other way to control period_size/buffer_size than with BASS_CONFIG_DEV_PERIOD/BASS_CONFIG_DEV_BUFFER. That's why this needs to be configurable.

[smoogipoo]

I think we can probably do this, overhead seems small.