Improve behavior of invert-color-include

[tobia]

This commit renders windows in the invert-color-include list with their frames non-inverted, that is, the color inversion is only applied to the client area. This makes sense because the frame is usually defined by the window manager and does not need color inversion.

Additionally the color hue is restored, so that only luminance is inverted. This is consistent with the behavior of other color inversion utilities (such as the Deluminate plugin for Chrome and Owl for Firefox) and has the effect of leaving red elements red, green ones green, and so on, while inverting the background and foreground luminance.

[tobia]

I have added more features to my branch and to this pull request:

1. Fixed glx-fshader-win option (custom GLSL shader) so that it can be specified in the configuration file (it was commandline-only)
2. Added a glx-fshader-win-file option that loads the shader from an external file.
3. Added a new uniform margin to GLSL shaders, containing the frame extents, so that a shader can invert the color of the client area, while leaving the frame intact.

I have also updated the sample GLSL shader. It employs a fast, custom luminance inversion formula that I developed, that keeps the color saturation and hue, and excludes the window frame decoration from the inversion. This GLX / GLSL version incurs no visible delay, as opposed to the XRender-based color inversion.