keyboard_states: use HashMap

[ConcurrentCrab]

keyboard_stream_map and keyboard_states have to be kept in sync, but beacause of states being a vector, it had different semantics during removal. If 2 devices were added and the first was removed then the vector shifts the second device to the front but the map obviously did not, leading to the collections becoming out of sync. This cause out-of-bounds errors on the states vector when accessing it using stream_map's keys.

This patch changes keyboard_states to be a map as well, and both maps are indexed using the udev input path as a key. A string key is not ideal, but is close to being the only unique ID for a connected device (physical path is not made serialised in many udev events for reasons unknown.), besides being easily accessible from both disjoint APIs being used here, evdev and tokio_udev.

An additional concern may be that tokio's StreamMap manages its own members and removes streams upon completion, but: a) We don't index into stream_map at all, only consume from it, so this will never be an issue b) the corresponding entry in states will be removed as well upon the udev remove event

[ConcurrentCrab]

Force-pushed some tweaks with logging and error handling.