Fix ReplayInputHandler not considering mutliple identical actions

[LumpBloom7]

KeyBindingContainers allow actions to be pressed down multiple times through separate bindings when SimultaneousBindingMode.All is used.

However, ReplayInputHandler did not take this into account. It will only generate an OnPressed event for the first press of the action, and will only generate an OnRelease when all presses have been released.

This change makes it so that input state changes occur not only based on whether the action exists, but also the number of occurrences of said action.

Before	After
Before.mp4	After.mp4

[bdach]

Not sure how to feel about any of this in general. The core problem here is that your ruleset is allowing more than one object to be hittable with the same binding at a time purposefully and our structures just falling over from that.

At the least if this is to pass review in my eyes, this needs a test case explaining what this change is for, and inline documentation next to the change spelling it out why Except() cannot be used (i.e. that it deduplicates multiple presses of the same action). And even then I wouldn't merge this myself with at least a second review from someone else.

[LumpBloom7]

Considering that rulesets are allowed to choose their own SimultaneousBindingMode without restrictions, it would make sense that the replay system should accommodate any of them.

My ruleset having multiple hit objects at the same time is irrelevant to the problem, as I am simply taking advantage of the flexibility permitted from targeting touch devices, where there can be multiple fingers tapping the same receptor. If a human can perform a sequence of inputs, the replay system must be able to replicate it.

That said, I will add a test case and some documentation later.

EDIT: My aim was bad and I pressed the "close PR" button.

[bdach]

My ruleset having multiple hit objects at the same time is irrelevant to the problem

I wouldn't call it irrelevant entirely. In every single default ruleset of ours it doesn't matter how many times a binding is pressed, the end result is still the same. But in your case you don't want it to be.

It's a significant paradigm shift with subtle implications and I'm not sure how we should be handling it if at all.

[LumpBloom7]

I wrote the requested tests, testing how ReplayState.Apply should work with each of the three SimultaneousBindingModes permitted by KeyBindingContainer.

I had to comment out many assertions because the actions triggered by ReplayInputHandler doesn't follow the same rules as regular input, effectively bypassing anything related to input queues and the input behaviour differences from SimultaneousBindingMode. (Related o!f issue)

The Except() implementation from before just so happens to match closely with how SimultaneousBindingMode.Unique would handle input. With that in mind, I also have doubts on this change, since this may break compatibility with existing rulesets that used SimultaneousBindingMode.Unique. I'm not sure on the way forward from here.

If replays are supposed to encode the inputs of a player or autoplay, then it would make sense that ReplayState.PressedActions would be a representation of currently pressed bindings (with duplicates) made by players, abstracted via ruleset xActions. These can then go through the regular input flow where it'll handle the input based on the rules built into InputManager