This is a set of model changes which is supposed to facilitate support
for custom sample sets to the beatmap editor that is on par with stable.
It is the minimal set of changes. Because of this, it can probably be
considered "ugly" or however else you want to put it - but before you
say that, I want to try and pre-empt that criticism by explaining where
the problems lie.
Problem #1: duality in sample models
---
There is currently a weird duality of what a `HitObject`'s samples will
be.
- If an object has just been placed in the editor, and not saved /
decoded yet, it will use `HitSampleInfo`.
- If an object has already been encoded to the beatmap at least once, it
will use `ConvertHitObjectParser.LegacyHitSampleInfo`.
As long as that state of affairs remains, `HitSampleInfo` must be able
to represent anything that `LegacyHitSampleInfo` can, if feature parity
is to be achieved.
Problem 2: The 0 & 1 sample banks
---
Custom sample banks of 2 and above are a pretty clean affair. They map to
a suffix on the sample filename, and said samples are allowed to be
looked up from the beatmap skin. `Suffix` already exists in
`HitSampleInfo`.
However, the 1 custom sample bank is evil. It uses *non-suffixed*
samples, *allows lookups from the beatmap skins*, contrary to no bank /
bank 0, which *also* uses non-suffixed samples, but *doesn't* allow them
to be looked up from the beatmap skin.
This is why `HitSampleInfo.UseBeatmapSamples` has been called to
existence - without it there is no way to represent the ability of using
or not using the beatmap skin assets.
As has been stated previously in discussions about this feature, it's
both a *mapping* and a *skinning* concern.
There are many things you could do about either of these problems, but I
am pretty sure tackling either one is going to take *many* more lines of
code than this commit does. Which is why this is the starting point of
negotiation.
Compare: https://github.com/ppy/osu/pull/26616
This came up elsewhere, namely in
https://github.com/ppy/osu/pull/28277#issuecomment-2133505958.
As it turns out, at least one beatmap among those whose scores had
unexpected changes in total score, namely
https://osu.ppy.sh/beatmapsets/971028#fruits/2062131, was using slider
velocity multipliers that were not a multiple of 0.01 (the specific
value used was 0.225x). This meant that due to the rounding applied to
`SliderVelocityMultiplierBindable` via `Precision`, the raw value was
being incorrectly rounded, resulting in incorrect conversion.
The "direct" change that revealed this is most likely
https://github.com/ppy/osu-framework/pull/6249, by the virtue of
shuffling the `BindableNumber` rounding code around and accidentally
changing midpoint rounding semantics in the process. But it was not
at fault here, as rounding was just as wrong before that change
as after in this specific context.
Closes https://github.com/ppy/osu/issues/25827.
The logic cannot be easily abstracted out (because
`CompareReverseChildID()` is protected and non-static on
`CompositeDrawable`), so a local copy was applied instead.
No testing as any testing would have been purely visual anyways.