This one turned out to be a bit more involved, due to tooltips being
shared and having the potential of being used somewhere where it
shouldn't be, due to the same content type matching.
That's the reason I've defined a protected `TargetContentType`, to be
able to separate "local player mod tooltips" and regular mod tooltips
apart.
Definitely unsure about the solution, but that's as far as I can think
of right now.
It turns out there's some quite convoluted scheduling / order of
execution requirements of ModSelectOverlay and ModSection. Applying
scheduling causes a runaway condition ending in zero frames after many
mod button changes.
I wanted to avoid rewriting the whole component, so have just moved the
schedule to guard against the part where drawables are actually changed.
As suggested in review, merge both HoverClickSounds constructors into
one accepting optional arguments. Due to existing usages the parameter
is added as second and supplied by name in ModButton.
As suggested in review, remove previously introduced HoverMouseUpSounds
and instead change effect playing logic in HoverClickSounds by moving it
out of OnClick() to OnMouseUp().
Users of the class can either use the existing constructor to play
the effect only on left click or use the newly introduced constructor
with the MouseButton[] parameter to specify which button clicks should
trigger the sound.
Because HoverClickSounds.OnClick() does not fire upon right clicking
on mod buttons, the sound effects that play on left and right click
were inconsistent. Introduce HoverMouseUpSounds drawable that allows
to play the click sound effect upon mouse up events for an arbitrary
set of mouse buttons and use it on mod buttons.
