feat(refactor): refactor to allow generic usage of komokana

[psych3r]

Resolves #64
Here's a summary of each module and what it does.

configuration:

• Didn't change
• Facilitates parsing the config file

kanata:

• Responsible for managing kanata's tcpstream object
• Responsible for connecting to kanata and starting kanata's listening loop

events:

• Responsible for handling Show & FocusChange events

main:

• Declares Provider trait
• Parses configuration file
• Creates shared (static) Kanata struct, connects to kanata & starts kanata loop
• Creates struct Komokana that implements Provider & starts the Provider loop

windows:

• Komorebi provider
• Connects to komorebi and starts komorebi's listener loop

osx:

• Placeholder for macOS provider

linux:

• Placeholder for Linux provider

[psych3r]

I thought it's better to introduce the macOS provider in a separate PR.
Also, I did minimal testing as I don't use komorebi.
My testing is focused on connecting to kanata (and reconnecting if needed).
It would be awesome if you tested the change with your configuration just to ensure that everything is working fine.

[LGUG2Z]

Really appreciate your initiative and work on this! I'm travelling without a computer until the end of next week, once I'm back home I'll build and run this PR for a few days 🤞

[psych3r]

Currently the event module relies on the Windows specific function GetKeyState due to virtual_key_overrides and virtual_key_ignores options.
I also think that the EVENT::Show variant is komorebi specific, and probably the title_overrides configuration option too.

I'm not sure whats the best way to go about this, but here are some options:

1. remove the event module and make event handling part of the provider.
2. have a feature for virtual_key that requires providers to implement a getKeyState function. And another feature for title_overrides.
   Use cfg feature conditionals where needed in the event and possibly the configuration module.

I am not a huge fan of the both option as I really like the idea of having a separate event module, and I don't think the features solution is particularly elegant.
What do you think?

Also, I think the exe option would benefit from supporting a matching strategy just like title.
Do you mind adding that?

[psych3r]

I put virtual_key_overrides and virtual_key_ignores behind a feature virtual_keys.
It requires providers to implement a get_key_state function.
As for title_overrides, I just made the title sent to handle_event an Option<&str> for flexibility.
The virtual_keys feature is a Windows only feature for now.
Provider implementations for other platforms get to choose whether to support the feature or not.

[LGUG2Z]

Hey @psych3r I'm going to have to back this PR out of master, at least temporarily; I have created a backup of the trunk with the changes integrated on https://github.com/LGUG2Z/komokana/tree/feature/refactor

Komokana is currently broken with komorebi due to named pipe and message size issues, so I need to switch over to a new UDS-based subscription implementation, however when doing this what the refactor currently on master this ends up deadlocking and I'm not able to understand where the issue is right now. I"m going to revert this out to get everything working again on master and then we can revisit this refactor afterwards.