Fix WaveformComparisonDisplay potentially crashing on invalid track length

[peppy]

As seen at https://github.com/ppy/osu/runs/17415814918#r0s2.

[bdach]

This guard is fine and all to address the direct failure, but what are the guarantees the component will function correctly after hitting it? By which I mean: say that the waveform regeneration is requested, but the track isn't loaded yet. This early-guard will prevent the crash, but what is going to ensure that the waveform gets regenerated at some later point?

There is this code in Update():

osu/osu.Game/Screens/Edit/Timing/WaveformComparisonDisplay.cs

Lines 168 to 178 in 0f7093c

	protected override void Update()
	{
	base.Update();
	if (!IsHovered && !displayLocked.Value)
	{
	int currentBeat = (int)Math.Floor((editorClock.CurrentTimeAccurate - selectedGroupStartTime) / timingPoint.BeatLength);
	showFromBeat(currentBeat);
	}
	}

but the guarantees it gives come with a lot of caveats (component needs to be not hovered, not locked, and even then showFromBeat() / showFromTime() have early-return guards that prevent possibly-redundant regenerations from happening etc.)

I'd probably see this as a flow based around Cached or something. Everything that forces the display regeneration would instead invalidate the Cached, and Update() would check if the Cached is invalid and if it's not, run this method.

[peppy]

Now that I think about it, this issue has actually been a thing for a while as far as I can tell. I've had cases the display doesn't update until I start to play the track (likely because it hit the case in this PR or something very similar but not as fatal).

Was hoping for a quick fix, but will look at doing this more correctly.

[peppy]

I've used Scheduler.AddOnce as it feels like a pretty simple solution here.

[bdach]

Seems okay