[WIP] Add Iterators and non-destructive updates for binding hotkeys.

[twestura]

Additional Hotkey Features

This adds new features to the hotkey file parsing library.

Iterators

Add iterators for both HotkeyGroup and HotkeyInfo. These structs can now be iterated over either by using the num_hotkeys or num_groups methods and a range, directly using a for loop thanks to IntoIter, or by calling the iter method to obtain an iterator over the internal vector.

Previously a hotkey for standard AoC could be iterated by using the enum to grab each of the predefined hotkey groups, then using that group's enum to obtain its hotkeys. But an arbitrary hotkey file can contain an arbitrary number of groups, each with an arbitrary number of hotkeys, this adds support for processing these files as well.

Display/ToString

Structs now have a display method that writes the string id and key codes.

A future feature would be to take in a language file and write the output using the strings from that file. The string_ids describing the commands are included in the hotkey file and can be read easily from the language file. But the keycodes still need to be translated into string_ids in order to obtain their string representations from the language file.

Bind/Unbind

Add bind/unbind methods to the HotkeyGroup and HotkeyInfo structs. These methods allow making a clone of the structs while updating a hotkey, so the original struct is unchanged. With the old API a client would need to clone the struct and then mutate the clone.

The interface design for mutating these structs can still use some work. In particular whenever the hotkey id is passed using one of the enum variants, as usize must be specified. The group ids work out be having two methods with different types, but there isn't currently a type to unify the hotkey ids across their various hotkey groups.

Various other bits

Hotkeys and HotkeyGroups now derive PartialEq and Eq. These traits make the structs easier to use in unit tests.
Hotkeys themselves now also derive Copy.
io::Result is not used explicitly instead of being imported to allow for using the standard Result type.

[goto-bus-stop]

sick, lgtm thus far. are you planning on doing the key name translation in this PR? I'm ok doing it now or later, hki was specifically <1.0.0 because it was unfinished to the point of being barely usable. we have a lot of 0.n.m versioning room to go before needing a stable interface 🐱

[twestura]

sick, lgtm thus far. are you planning on doing the key name translation in this PR? I'm ok doing it now or later, hki was specifically <1.0.0 because it was unfinished to the point of being barely usable. we have a lot of 0.n.m versioning room to go before needing a stable interface 🐱

That's the next thing I was going to work on, might as well do it in this PR as well. Most of the ids should be pretty straightforward to figure out from the key-value file.

[goto-bus-stop]

@twestura I'd like to get this in as is if you don't mind, then the remaining things you were planning on doing in this PR can be landed separately later.