Support for using any number of CRTC:s in any number of screens

[maandree]

This pull request continues #42 (Support for running Redshift outside X) by
adding support for using any number of CRTC:s in any number of screens with
individual gamma correction for each monitor.

The configurations are backwards compatible but are extended so that you
can select any monitor and apply gamma corrections individually by specifying
one section in the configuration file per monitor with the same name as the
adjustment method. For example:

[redshift]
adjustment-method=randr
gamma=1:1:1
; this gamma setting will be used if not specified otherwise

[randr]
screen=0
crtc=0
gamma=1.1:1.1:1.1

[randr]
screen=0
crtc=1
gamma=1.2:1.2:1.2
; screen=1 with crtc=0 will also work, although I cannot say
; for sure because I only have one screen, with two outputs.

The reason the sections are named as the adjustment method is
so that it is simple to have adjustment method dependent settings.
For example, if I use DRM the CRTC:s will be swapped so a can
extend the example above with:

[drm]
card=0
crtc=1
gamma=1.1:1.1:1.1

[drm]
card=0
crtc=0
gamma=1.2:1.2:1.2

[maandree]

I have rebased and squashed this branch.

[jonls]

Can you please rebase this on the master (instead of merging master into your branch)? Maybe it would be a good idea to split the changes for each gamma method into separate commits so they can be reviewed separately. Also, maybe all the (void)variable; edits can go into a separate commit (I assume these are just to suppress some overeager warning setting) and maybe drop them entirely since they are not needed.

[maandree]

I have rebased and splitted into logical steps. I also added an update to .gitignore.

(void) variable and cast to unsigned as added to suppress the overwhelming
amount of worknings when a was compiling, to make it easier to read the output.
I compile with -Wall -Wextra -pedantic to reduce errors and make sure that I do
not use any feature that is not portable.

[jonls]

Thanks, I've merged the two minor commits.

[maandree]

@jonls how is it looking on merging this and its child branches?

[jonls]

@mandree I'm a bit busy these days so I decided it was more important to push out the 1.9 release since I think we had some good features ready to go. I will start merging this as soon as I find some time. I see that you made some other pull requests but they seem to be based on this, no? I will focus only on merging this branch if it is the basis of the following pulls.

Also, please don't merge master back into pull requests. If you need new features from master (i.e. they are essential to your patch) you can do a rebase on master.

[maandree]

Okey.
I was wondering because I was not sure whether to wait or make pull request #61,
which obsoletes this pull request and all pull requests based on this pull request.

[jonls]

Alright, if you make something obsolete please close it so I won't spend time reviewing it ;) It's generally way easier for me if you break the pull requests up into small self-contained units.

[maandree]

Sorry about that on 61, I did not want to have to rewrite a bunch of stuff if I missed something.