The naming for "blur-compat" was misleading since the setting
actually affects more than just blur affects. Additionally
forwarding storage resolution but forcing an aspect ratio
of 1.0 for the video is likely to result in odd rendering
and there’s no known usecase for it.

Both options control which video properties are exposed to libass
so to fix the aforementioned issues merge these settings into one
tri-state sub-ass-use-video-data.

The default V keybind now cycles through all states of
use-video-data instead of toggling vsfilter-aspect-compat.

Resolves: mpv-player#10680

It is unclear whether there actually is any usecase for this option
which isn't better served by sub-ass-use-video-data and/or LayoutRes
overrides, but prior to the introduction of sub-ass-use-video-data
it was possible to pass along storage resolution while faking an
aspect ratio of 1:1.
sub-ass-video-aspect-override=1 combined with sub-ass-use-video-data=all
now makes this possible again.

The uper limit of a 10:1 aspect matches
the general video-aspect-override option.

These might be useful

This would cause us to exit out of the loop with a goto anytime we ran
into XRUN or DRAINING and preparing PCM for use failed.

ALSA API reports -EPIPE even when the the device is lost, which we
currently always assume to be an XRUN. If we assumed XRUN 10 times and
didn't manage to recover, just consider the device lost and try to
reconnect. Allows ao_alsa to recover from alsa server being killed then
reinitialized. And even in the worst case, this should be better than
the status quo of mpv attempting to prepare a PCM device indefinitely
until the user restarts mpv.

This is admittedly not ideal, and I don't think the -EPIPE hack is
necessary anymore, but I can only test on my setup and removing the
'assume -EPIPE is an XRUN' hack might break some setups for whatever
mysterious reasons.

Enabled the ruff python linter in CI, and resolved the issues that were
detected by it.