Remove InputStreams using a subtrait of UserInput, allowing users to add their own input kinds

[alice-i-cecile]

Fixes #569.

As discussed there, we store all of the UserInput data in a centralized store, and then update these via independent systems.

We can work around the limitations of object safety by moving the required methods out into its own trait, UpdateableInput. Add some system sets, an associated type for the data to access and we're looking good.

Initial progress

Unfortunately, many of our user input types actually represent a configured type: we can't trivially use a single map of "what does the input data look like per type". This crops up in two places:

1. The virtual axis / virtual dpad types, where the buttonlikes required to be pressed can differ.
2. The axis / dualaxislike types, which can store input postprocessors.

Our options here are:

1. Keep the existing design, but make it extensible by taking &World instead of &InputStreams.
2. Only store raw values in CentralInputStore: chords, dpads and processed axislike data will have to reference this and recompute it.
3. Add a system per configurable input, using capturing closures and far too much plumbing.

IMO Option 2 is the only viable choice here: 1 imposes too much system ordering pain, and 3 simply won't work very well.

To do

• remove InputUpdateSystem
• remove DummyResource
• update docs on UpdateableUserInput
• implement UpdateableInput for all of the buttonlikes
• implement UpdateableInput for all of the non-gamepad dual-axislikes
• implement UpdateableInput for the gamepad dual-axislikes
• replace all references to InputStreams with CentralInputStore
• remove InputStreams
• figure out how to deal with gamepads
• update CHANGELOG.md
• make CI pass