Closes#25663 (again).
As it turns out, in some scenarios it can be the case that the current
game-global `Beatmap` is not valid for the current game-global
`Ruleset`. The validity of one and the other in conjunction is only
really validated by the song select screen; elsewhere there is no
guarantee that the global beatmap is playable using the global ruleset.
However, this only comes up in very specific circumstances, namely one:
when trying to autoplay a catch beatmap with osu! ruleset globally
active via the skin editor flow.
`Player` is responsible for retrieving the beatmap to be played. It does
so by invoking the appropriate beatmap converter and asking it if the
beatmap can be converted:
6d64538d7a/osu.Game/Beatmaps/WorkingBeatmap.cs (L262-L266)
If the code above throws, `Player` actually silently covers for this, by
trying the beatmap's default ruleset instead:
6d64538d7a/osu.Game/Screens/Play/Player.cs (L529-L536)
However, for the pairing of osu! ruleset and catch beatmap, this fails,
as `OsuBeatmapConverter`'s condition necessary for permitting conversion
is that the objects have a defined position:
6d64538d7a/osu.Game.Rulesets.Osu/Beatmaps/OsuBeatmapConverter.cs (L25)
which they will do, due to the fact that all catch beatmaps are really
just osu! beatmaps but with conversion steps applied, and thus `Player`
succeeds to load the catch beatmap in osu! ruleset.
In the skin editor scenario, this would lead to the secondary failure
of the skin editor trying to apply `CatchModAutoplay` on top of all
of that, which would fail at the hard-cast of the beatmap
to `CatchBeatmap`.
Until now, the only usage of ruleset layers was where there is both a
ruleset specific and non-ruleset-specific layer present. The matching
code was making assumptions about this.
As I tried to add a new playfield layer which breaks this assumption,
non-ruleset-specifc components were not being displayed in the toolbox.
This turned out to be due to a `target` of `null` being provided due to
the weird `getTarget` matching (that happened to *just* do what we
wanted previously due to the equals implementation, but only because
there was a container without the ruleset present in the available
targets).
I've changed this to be a more appropriate lookup method, where the
target for dependency sourcing is provided separately from the ruleset
filter.
This also moves the beatmap skin disable toggle to on toggle, in line
with review feedback.
I've decided to always apply the disable, not just on the `Player`
screen. It should be assumed that if a user is in the skin editor they
are never going to need access to this anyway.
