fix(whkd): bind rwin by default when binding win

[akozlev]

Thank you for you work on whkd and komorebi.

I was experiencing an issue with binding the Windows key. I was able to use the left windows key to trigger a hotkey but not the right one. Let me know if this is the intended behavior. Otherwise, please read my reasoning below about why I created this PR.

The user might expect that a hotkey like win + k would trigger regardless of which windows key is pressed.

This pull request ensures that VKey::RWIN is registered alongside with VKey::LWIN when specifying a win as a modifier. [1]

// https://github.com/iholston/win-hotkeys/blob/b967bca6559a1b34ac09425389be46117554be2a/src/keys.rs#L547  
"SHIFT" => VKey::Shift,
"CTRL" => VKey::Control,
"CONTROL" => VKey::Control,
"ALT" => VKey::Menu,
...     
"WIN" => VKey::LWin,

This is required because win-hotkeys doesn't handle lwin and rwin the same way that it handles shift, alt and ctrl.

Things to consider:

• If pause hotkey is assigned to a hotkey with win modifier it will not register rwin by default.
• Hotkeys are not checked for conflicts. For example, if you register win + k and rwin + k it might result in a conflicting binding because of the default.

Let me know if there is anything you would like me to modify.

[1] https://github.com/iholston/win-hotkeys/blob/b967bca6559a1b34ac09425389be46117554be2a/src/keys.rs#L547

[akozlev]

Hey @LGUG2Z,
Do you have time to share your thoughts on this PR?

Thanks.

[LGUG2Z]

Hotkeys are not checked for conflicts. For example, if you register win + k and rwin + k it might result in a conflicting binding because of the default.

I think the only change I'd like to see before adding this is that we ensure that binds to rwin will take take priority over the default double-bind with win

[akozlev]

Thank you for the feedback, @LGUG2Z.

I've updated it to check the initial bindings list for ones specified with rwin and only create a new rwin binding if is not yet specified. I've used a HashSet for comparison to ensure that equality is not dependent of the order of the specified keys.
I added a couple of simple tests to verify the behaviour.