Added InputSource as an ID for input event sources

[bushrat011899]

Objective

• Fixes support multiple pointer devices #15
• Increase parity between gamepad and non-gamepad input types.

Solution

• Added InputSource as a platform and library agnostic identifier for input-like events. This type is purely an identifier with no inherit meaning beyond its self comparison. It is up to the writers of input events to provide any additional meaning to these
• Updated input events to include an InputSource field, disambiguating the source of the event.

---

Changelog

• Added InputSource identifier type.
• Added InputSources resource for creating InputSource IDs. Since InputSource is purely a unique ID, InputSources is just a counter.
• Updated gamepad, mouse, keyboard, touchpad, etc. inputs to include a source: InputSource field.

Migration Guide

• Input types now include a source field of type InputSource. If you don't require it when reading, discard its value (e.g., during pattern matching). If writing one of these input events, use the InputSources resource to create an InputSource ID that you must manage.

---

Tasks

• Capture winit::event::Event::DeviceEvent's, not just WindowEvent::DeviceEvent (these are confusingly different). Currently this only provides meaningful disambiguation for Gamepad events, and MouseMotion (at least on my test platform). winit provides a DeviceId with WindowEvent's, but for whatever cause (Windows, winit, etc.), the ID provided for those events is always for the "primary" device. Whereas, DeviceEvent events do include the specific device. This can currently be best observed in the mouse_input_events example, which will disambiguate MouseMotion, but not MouseButtonInput. I think the solution to this is to duplicate the event types (similar to CursorPosition vs MouseDelta).
• Expand documentation. It's the bare minimum to avoid linting issues.
• Explore "input sources as entities". Currently, I don't like this framework, since we don't have an efficient way to retrieve an Entity by an arbitrary value (e.g., a winit DeviceId component), and registering a new input source would require world access for allocating an Entity. But, it could be powerful for adding arbitrary metadata (e.g., GamepadInfo) to input sources.

Notes

• I'm deliberately not modifying the Inputs resources to provide this extra information right now to keep the scope of changes small. Providing this information on the input events is, in my opinion, the bare minimum to allow a Bevy user to utilise multiple mice, keyboards, etc.
• While this may seem like a pretty esoteric feature to support in Bevy, I do think it's worthwhile. There are many instances of flight simulator gamers trying to retroactively add this support to existing games. Macro-heavy applications have a similar problem. Exposing this to Bevy users will allow them to decide if these kinds of features are something they'd like to support.
• I want this to eventually reach a form of feature parity with gamepads, since we have an established API for disambiguation between them already. This is why I've modified the Gamepad type to contain an InputSource instead of a usize as its ID.

[rdrpenguin04]

@bushrat011899 Are you still working on this PR? If not, I could possibly adopt it.

[bushrat011899]

Yeah I've let this one get away from me unfortunately! If you would like to take this PR and run with please feel free to do so!