Fix InputManager including non-loaded direct children in input queue

[frenzibyte]

• Closes Holding keys before gameplay starts can result in incorrect input handling osu#23555

KeyBindingContainer gets into a weird state when handling input while it's not loaded. Since it's not loaded, KeyBindings would be null since it only gets populated in LoadComplete, so no press/release events are propagated to children for the first key. However, the key gets stored in pressedInputKeys, and later on, when the next key is pressed, the old key incorrectly becomes processed as a new binding as well, causing the double-press issue.

KeyBindingContainer was not supposed to enter the input queue if it's not fully loaded in the first place, but turns out InputManager was incorrectly adding it (by bypassing ShouldBeConsideredForInput).

[bdach]

One thing that I wondered with this test is what happens once Enter is released after the key binding container is loaded / added. And the answer to that is nothing happens, i.e. the input manager does not receive the release of the Enter key. Which is probably a good thing, as it's better to send nothing than half a press, but it still has me worried about the implications on game usages.

So this is probably okay, but I'd appreciate assurances that nothing falls over game-side with this change applied, i.e. running game-side tests and making sure nothing fails.

[frenzibyte]

One thing that I wondered with this test is what happens once Enter is released after the key binding container is loaded / added. And the answer to that is nothing happens, i.e. the input manager does not receive the release of the Enter key. Which is probably a good thing, as it's better to send nothing than half a press, but it still has me worried about the implications on game usages.

If by "input manager" you mean the key binding container, then that is correct. I had run game-side tests beforehand and ensured nothing broke, but I'll check again to confirm.