I was trying to understand the logic here, and noticed the indirection
via a QualityResolver interfaces is pretty unnecessary. Just branching
directly makes the logic a lot easier to follow.

The `-999` sentinel value is a bit dumb, but java does not recognize
that videoIndex is always initialized.

Nice side-effect, the `Resolver` interface was completely unused and
can be dropped.

The function never returns `null`.

This should make the purpose of these functions more clear.

All functions that set videoIndex return `-1` if the list is empty, so
we don’t have to check manually for that case.

I’m somewhat more questioning why `StreamInfoTag.of` allows the index
to be out-of-bounds in the constructor, that should be an error.

Instead of allowing to pass arbitrary out-of-bounds indexes to these
bean classes, ensure that the index is always valid for the list.

This is always true for our filter functions, except they all return
`-1` if the list was empty. We have to check/assert that beforehand.

This improves the logic somewhat, because fetching the stream always
returns something now.

Ideally, we wouldn’t be filtering stuff and then passing indices
around everywhere, but that’s the current state of things.

~~~

I took the liberty to remove the `.of`-wrappers, because they don’t
really add much compared to just calling the constructor here.

Why would you serialize objects to avoid a null check, that’s just
weird.

Instead of the `trackId`, which is only ever set for the `youtube`
backend, we use the audio stream language and tracktype. These are
`null` for youtube videos without language selector, leading to a
single audio stream being selected.

For media.ccc.de, the language on audio tracks is always set
correctly, meaning for a video with German and English tracks we get
two groups, which are then sorted according to the preferences of
users.

I verified that youtube still works by playing
https://www.youtube.com/watch?v=8bDRVP9xSfc
and selecting the different audio streams, going to background etc.
and also tried with a video without multiple audio tracks.

For media.ccc.de, it will select the right audio track as well.

Unfortunately, media.ccc.de returns videos with multiple audio track
muxed into the video itself, which is still buggy because the wrong
track is selected by default. This is gonna be fixed/worked around in
the next commit.