Input module ergonomics and features

[AlisCode]

Fixes #21 .

Refactors the Input module.

• Follow Rust API Guidelines "Types eagerly implement common traits (C-COMMON-TRAITS)"
• Adds support for Gamepad (+ tests)
• Adds support for Multiplayer (+ tests)
• Adds an InputStateBuilder
• Add Input example :
  • Move squares around,
  • Change their color by pressing a button
• Some cleanup (cargo fmt, comments)

Breaking changes

• InputState has been renamed to PlayerInputState (and tests updated accordingly)
• InputState is now a struct that holds multiple PlayerInputState for multiplayer purposes. The public API remains globally the same, though.

Notes

• While InputState is still possible to build with InputState::new() and now also implements Default for SPECS usage, building an InputState from scratch should be discouraged, as it is preferable to use the new InputStateBuilder.
• I'm not really glad of the implementation of multiplayer support : I think code reuse could be done better, but the public API is clean and this PR does not break tests.

Caveats

• Mouse support still not implemented
• Joystick support still not implemented. This one might be a bit trickier because ggez exposes Axis values as f32, which are !Hash and !Eq, making them unusable for HashMap keys. If you have any insights feel free to let me know.
• Writing InputBinding as shown in the example is a bit verbose, it might also be possible to provide a from_config method to create it directly from a .ron file. Adding a dependency is a decision that should not be taken lightly though, and RON does not seem to be part of the ggez "ecosystem" yet, so that's a no-go for now.

[icefoxen]

Awesome, thank you!

Specific points:

• Not sure at a glance where we would need to use a gamepad's axis as a hashmap key, reference?
• Not sure how multiplayer support could be done better using this model, I'll take it for now.
• To keep it "ggez-y", perhaps load key bindings from TOML instead of RON? I like RON just fine but TOML is something every Rust dev is going to know anyway.

It honestly may be easier to have a macro that takes in a list of event inputs and generates code to turn them into states in a struct rather than using a hashmap, so you could just do input_state.player[0].axis_y instead of input_state.get_player_axis_raw(Axes::Vert, 0). But Magical Codegen Macros are also a little counter to the ggez ethos, so, I dunno.

[AlisCode]

Meh.

Silly me, I got things mixed up and instead of just trying and eventually noticing that we don't store them as keys, I just packed my PR up and called it a week-end.

I'll have another PR on the way soon-ish bringing:

• Input loading via TOML,
• Mouse,
• Joystick support