[Feature] Added improved automatic closing of the notification on charging state change

[Nikl174]

What changed

To improve the performance of closing the notification without decreasing the performance of batsignal (increasing the polling rate) I implemented a file watcher (for all batteries detected) via the kernel API inotify and conditional variables for signaling.

How does it work

Here a summary of what happens:

1. inotify initialized (creates file descriptors(fd) for each file watched, which can be read on file events)
2. threads for each battery is started which reads the fd
3. batsignal continues as always, except that its not a normal wait, it now waits for the conditional variable to get signaled
4. the inotifiy threads block on fd read until the battery state file changes
5. on a file change: conditional variable is signaled and the batsignal cycle is continued to the next wait
   (same on timeout of the wait for the conditional variable)

Whats left to do

• Currently there is a bug on closing batsignal which is related with the signal handling and blocking (FIXED)
• I'm not that familiar with plain c so it would be nice, if someone could look over the code, I'm not that familiar with the C-conventions and maybe i made a big mistake there @electrickite
• Testing from others would be nice

Note: the fist commit is a little restructure in src and include directory, if this is unwanted, i can revert it

[Nikl174]

It is also possible to implement it without starting any threads(using poll with a timeout on the watching fd), but then i need to detect, which battery is in use and I"m not sure, if this then reliably closes the notification when 2 (or more) batteries are in use and then switched by the firmware....

[Nikl174]

Should work now stable, in the log-messages I saw that may events occurred on state-file-change which results in many recalculations in the batsignal cycle. I could add delay decrease the number of events, but its not necessary though.