Closes https://github.com/ppy/osu/issues/25608.
Logic mostly matching stable. All operations are done on `ComboOffset`
which still makes overridden combo colours weirdly relatively dependent
on each other rather than them be an "absolute" choice, but alas...
As per stable, two consecutive new combos can use the same colour only
if they are separated by a break:
52f3f75ed7/osu!/GameModes/Edit/Modes/EditorModeCompose.cs#L4564-L4571
This control is only available once the user has changed the combo
colours from defaults; additionally, only a single new combo object
must be selected for the colour selector to show up.
As I look into re-implementing the ability to choose combo colour for an
object (also known as "colourhax") from the editor UI, I stumble upon
these wretched ternary items again and sigh a deep sigh of annoyance.
The structure is overly rigid. `TernaryItem` does nothing that
`DrawableTernaryItem` couldn't, except make it more annoying to add
specific sub-variants of `DrawableTernaryItem` that could do more
things.
Yes you could sprinkle more levels of virtuals to
`CreateDrawableButton()` or something, but after all, as Saint Exupéry
says, "perfection is finally attained not when there is no longer
anything to add, but when there is no longer anything to take away."
So I'm leaning for taking one step towards perfection.
It didn't ever really make sense for it to be sharing the implementation
details of that (e.g. colouring of primary/dangerous actions), and with
the hotkey display things got outright hacky, so I'm decoupling it
entirely.
Bookmarks don't show on real beatmaps, but they do show in test scenes
(namely `TestSceneEditorSummaryTimeline`).
Also does some more changes to adjust the markers to the latest updates
to other markers.
This removes the BPM display, which is commonly cited to have
no functional purpose by users, and reduces the height of the bottom bar
in exchange for more space for the playfield.
