This commit removes ISkinnableSwell for taiko swell animations. In place
of it, an event named UpdateHitProgress is added to DrawableSwell, and
the skin swells are converted to listen to said event and
ApplyCustomUpdateState, like how spinner skinning is implemented for
std.
Delaying the expiry of the drawable hitobject can potentially be dangerous and gameplay-altering when user inputs are accidentally handled. This is why I found a test necessary.
Done for two reasons:
- During review it was requested for the logic to be moved out of
`BezierConverter` as `BezierConverter` was intended to produce
"lazer style" sliders with per-control-point curve types,
as a future usability / code layering concern.
- It is also relevant for encode-decode stability. With how the logic
was structured between the Bezier converter and the legacy beatmap
encoder, the encoder would leave behind per-control-point Bezier curve
specs that stable ignored, but subsequent encodes and decodes in lazer
would end up multiplying the doubled-up control points ad nauseam.
Instead, it is sufficient to only specify the curve type for the
head control point as Bezier, not specify any further curve types
later on, and instead just keep the double-up-control-point for new
implicit segment logic which is enough to make stable cooperate
(and also as close to outputting the slider exactly as stable would
have produced it as we've ever been)
The logic in `LegacyBeatmapEncoder` that was supposed to handle
the lazer-exclusive feature of supporting multiple slider segment types
in a single slider was interfering rather badly with the Bezier
converter. Generally it was a bit difficult to follow, too.
The nice thing about `BezierConverter` is that it is *guaranteed* to
only output Bezier control points. In light of this, the same double-up-
-the-control-point logic that was supposed to make multiple slider
segment types backwards-compatible with stable can be placed in
the Bezier conversion logic, and be *much* more understandable, too.
To be used in the editor, for the beatmap submission wizard.
I've recently been on record for hating "abstract" as a rationale to do
anything, but seeing this commit ~3 months after I originally made it,
it still feels okay to do for me in this particular case. I think the
abstraction is loose enough, makes sense from a code reuse and UX
consistency standpoint, and doesn't seem to leak any particular
implementation details. That said, it is both a huge diffstat and also
potentially controversial, which is why I'm PRing first separately.
