Adjust mania hit windows with DT/NC/HT/DC gameplay rate

[smoogipoo]

Resolves #24603

I had two attempts at this:

1. Add local HitWindows proxy methods to DrawableManiaHitObject that applies local adjustments.
   1. Advantage: Works for all mods.
   2. Disadvantage: Needs significant supporting code/API considerations for BarHitErrorMeter.
2. Adjust hit windows via mods.
   1. Advantage: Works for BarHitErrorMeter, minimal API consideration.
   2. Disadvantage: Doesn't immediately work for time-ramping mods (ModWindUp).

This PR implements option 2, with the idea that time-ramping mods are more of an edge case that could be implemented later.

A sample implementation for time ramping mods may be found here: https://github.com/smoogipoo/osu/tree/mania-time-ramp-mod-hit-windows , which is exposed as a bindable via an IApplicableHitWindows interface that BarHitErrorMeter could bind to. I'll PR this as a follow up if this PR is accepted.

I'm unsure of whether the over-engineering in this PR (and the follow-up) is justified. If not, I'll implement locally in the relevant mods, figure out something better, or accept any suggestions.

[bdach]

I'm generally quite ok with this diff code-wise, but is it possible to have some testing here, along the lines of TestSceneManiaHoldNoteInput? I'd be more confident having it.

Alternatively, do you have a manual testing methodology you can suggest here?

[bdach]

In my rather rudimentary testing, looks to work okay

[bdach]

Not super sure about this initialisation either, but I guess the value is never used so it's probably okay... It just looks a smidge weird that this sets no-rate windows and the actual magic that undoes rate happens via the default interface implementation.

Is changing to a get-only property or a protected method something you'd be willing to entertain? Just for slightly more explicit code, is all.

[smoogipoo]

It can't be get-only if the implementation modifies it. Perhaps CreateDefaultHitWindows() is a possibility?

[bdach]

That would work for me, I was just curious if you had any other objections (related to performance, or to the follow-up PR that does wind up/down that you talked about in the OP).

[smoogipoo]

It's still an isolated implementation, I'm fine with any if it gets the job done. We can figure out WU/WD when we cross that road.

[smoogipoo]

This is a bit more complicated to make work, so let's keep it as is for now. The likely path here is to extract the interface implementation into an auxiliary class (HitWindowRateAdjuster, or something like that).

It would be good to tackle this once we know the exact requirements with consideration for WU/WD.