Large ticks are not a thing in mania anymore, so the judgement counter
tests began to fail as `LargeTickHit` is no longer a valid hit result
in that ruleset.
For a judgement result to show up on the colour hit error meter, it has
to be two things: be scorable, and not be bonus.
`ComboBreak` happens to meet both of those criteria - it impacts score
indirectly via decreasing the combo portion, and isn't bonus. Therefore
it would show up on the colour hit error meter, but because
`OsuColour.ForHitResult()` wasn't handling it explicitly, it was
painting the result in light blue, which isn't ideal for a miss type
judgement. Therefore, use red instead.
There is possibly an argument to be made that this judgement should not
show up on the colour hit error meter at all, but I think it's actually
okay for it to be this way. In any case it doesn't appear to be anything
so major as to warrant blocking the hold note tick removal at this time.
It's not a timed object, so following precedent, it should have empty
hitwindows.
This is not actually just aesthetics; several components check whether a
hitobject has empty hitwindows to determine whether to include it on
various HUD displays and results screen components where timed objects
are explicitly involved.
The reasoning is explained in the inline comment, but basically this was
getting blocked by `isPaused` being in an initial `true` state (as it is
on construction), while the source clock was still `IsRunning`.
There's no real guarantee of sync between the source and the `isPaused`
bindable right now. Maybe there should be in the future, but to restore
sanity, let's ensure that a call to `Reset` can at least stop the track
as we expect.