basic keybind logic

[JackCrumpLeys]

related to #648

• [x] action registering and dispatching based on input key-binds
• [x] Migrate old code to new system
• [ ] ~using a config file to deserialise and serialise user defined key-binds~
• [ ] ~Bubble up config errors (we just panic at the moment)~

[Indy2222]

I hoped that we will be able to utilize leafwing-input-manager instead of doing all the work from scratch.

Notes about how we can structure the usage of leafwing-input-manager:

• leafwing-input-manager (InputManagerPlugin) puts all relevant systems in PreUpdate schedule. We need to move that to Input and make sure that a) there is no one frame delay between raw inputs from bevy and when leafwing-input-manager processes them, b) handling of the actions is done after the relevant systems from leafwing-input-manager run.
• All input code lives in controller (which is intended to contain all user control code).
  • This crate contains a bit more than that and we should fix that in the future. However, it is an independent task.
• There is an enum (a single one for now?) with all keyboard/mouse actions (implementing leafwing_input_manager::Actionlike).
  • In later stages, this would be (de)serializable so it can be used in config.
  • InputMap from leafwing_input_manager already is (de)serializable.
• During startup, InputMap and ActionState are created.
  • These should be global (we do not need per-entity control).
  • In later stages, the input map would be loaded from configuration.
• InputManagerPlugin is registered or we add the relevant systems manually so that they can be executed during Input schedule.
  • We might ask people from leafwing-input-manager whether it is possible to add a bit more scheduling flexibility to leafwing-input-manager.
• ClashStrategy::UseActionOrder is used - to reconsider.