Add ValueChange and AxisPairChange variants to ActionDiff

[WesleyClements]

In this PR I added an ActionDiff::AxisChanged variant. This is meant to allow for transmitting changes to axis input types across the network. I've updated the relevant systems to handle creating events for this variant on the client and consuming them on the server. I've been using this solution in my own projects for a little bit and it seems to be working but I'm new to rust in addition to the bevy ecosystem so would really love some feedback as to if this seems like a reasonable solution. There are three potentially breaking changes. First I had to remove Eq and Hash from ActionDiff as f32 doesn't implement them. Second I had to add a local resource to the generate_action_diffs system to keep track of if the axis actually changed. Lastly I had to add a requirement that the ID type implement the Hash trait as it is being used a key for a hashmap.

Fixes #342

[WesleyClements]

I know this will add an extra minimum necessary bit to distinguish between the variants which can potentially add up especially if sending in bulk/with a lot of players. I've been using bincode for serialization which (for the way I have it configured at least 🤷) seems to use at least a byte for the variant signifier so this change wouldn't increase the overhead. Regardless, this seems to be the most ergonomic approach as it makes it simpler for the user to only have to handle passing/serializing/deserializing one event type between client and server. That being said, an alternative to this might be to create a separate struct for the AxisDiff and send a different event for those changes. That would force the user to handle both events and figure out how to differentiate between them across the network. I'm using bevy_renet for networking and from what I've seen it wouldn't be too difficult to create a second channel to send the AxisDiffs on. That being said, I'm not sure I would actually reduce the data being sent over the network. I could imagine that the client is typically only changing 8-ish inputs each update which would mean that the extra variant would tack on an extra byte per request. I'm making another assumption that the overhead from making a request on two channels is comparable to that extra byte per request. I could be very off here and definitely would like feedback and thoughts but those are my follow up thoughts after sleeping on this PR and panicking that I hadn't thought through it thoroughly enough 😁.

[WesleyClements]

I didn't think it through enough. I realize this doesn't handle single axis input types. I will think of a solution to this problem and implement it real quick.

[WesleyClements]

I added support for syncing ActionData.value by including a fourth variant. I also had to refactor the generate_action_diffs. It would have been easier if I knew how to know the input type of an action but I just assumed that if the value of an action is 1.0 that it is a binary input. As part of this change I removed the behavior of sending two events when an axis input is pressed. It will no longer send a Pressed event in addition to a AxisPairChanged event. I'm not set on any names for variants. It does seem odd to me that ValueChanged is being sent as the "pressed" event but I guess you don't really press an axis any how.

[alice-i-cecile]

Good, this seems like a sensible approach! Could you add some more tests to help us spot regressions?

[WesleyClements]

Most definitely!

[WesleyClements]

This is now dependent on #424