Merge pull request #31481 from Susko3/update-osu-stable-from-registry

Add new osu!(stable) registry ProgId

Merge branch 'master' into update-osu-stable-from-registry

Merge pull request #31364 from bdach/editor-storyboard-display-2

Display storyboard in editor background

Ignore realm `List<T>` type

Merge pull request #31462 from bdach/ternary-button-is-bad

Simplify editor "ternary button" structure

Add new osu!stable registry ProgId

Merge pull request #31453 from bdach/fix-juice-stream-placement-offset

Fix juice stream placement blueprint being initially visually offset

Simplify editor "ternary button" structure

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.

Fix juice stream placement blueprint being initially visually offset

- Closes https://github.com/ppy/osu/issues/31423.
- Regressed in https://github.com/ppy/osu/pull/30411.

Admittedly, I don't completely understand all of the pieces here,
because code quality of this placement blueprint code is ALL-CAPS
ATROCIOUS, but I believe the failure mode to be something along the
lines of:

- User activates juice stream tool, blueprint gets created in initial
  state. It reads in a mouse position far outside of the playfield, and
  sets internal positioning appropriately.
- When the user moves the mouse into the bounds of the playfield, some
  positions update (the ones inside `UpdateTimeAndPosition()`, but the
  fruit markers are for *nested* objects, and
  `updateHitObjectFromPath()` is responsible for updating those...
  however, it only fires if the `editablePath.PathId` changes, which it
  won't here, because there is only one path vertex until the user
  commits the starting point of the juice stream and it's always at
  (0,0).
- Therefore the position of the starting fruit marker remains bogus
  until left click, at which point the path changes and everything
  returns to *relative* sanity.

The solution essentially relies on inlining the broken method and only
guarding the relevant part of processing behind the path version check
(which is actually updating the path). Everything else that can touch
positions of nesteds (like default application, and the drawable piece
updates) is allowed to happen unconditionally.

Merge pull request #31459 from peppy/fix-replay-frame-separation

Fix rate adjustments changing the spacing between replay frames

Merge pull request #31438 from Susko3/show-in-windows-association-menus

Show osu!(lazer) in windows "default apps" menus

Add reason for making test interactive-only

Fix rate adjustments changing the spacing between replay frames

Add test showing that rate adjustments cause discrepancies in replay frame precision

Merge branch 'master' into show-in-windows-association-menus

Merge pull request #31452 from bdach/delete-juice-stream-if-path-degenerates

Delete entire juice stream when only one vertex remains after deleting another vertex

Merge pull request #31454 from bdach/select-closest-timing-point-on-every-enter

Select closest timing point every time the timing screen is changed to

Merge branch 'master' into show-in-windows-association-menus and adapt ApplicationCapability

Merge branch 'master' into editor-storyboard-display-2

Merge pull request #31450 from peppy/association-manager-cleanup