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.
An end result of #22674 is that `SkinBlueprintContainer`s are only ever
created by supplying a `SkinComponentsContainer` to them. However,
`SkinBlueprintContainer` still contained remnants of code that suggested
it was designed to handle cases where more than the drawable supplied to
it contained more than one `ISerialisableDrawableContainer`, or even
zero.
The zero path is totally dead right now (because every
`SkinComponentsContainer` is *by necessity* an
`ISerialisableDrawableContainer`), and the more-than-one path is dead
*for now* (and potentially forever?). Therefore, just hard-couple
`SkinBlueprintContainer` to receive a single target container.