Wait for fade-to-black to finish before stopping display updates

Hammerhead devices a) ignore display brightness changes if display
updates are disabled b) leave the display backlight powered on if
effective brightness is not zero at suspend time.

Wait for fade-to-black brightness change to finish before telling
compositor to stop display updates.

[mce] Wait for fade-to-black to finish before stopping display updates. Fixes JB#21833
Stage non-zero brightness before powering up display

Hammerhead devices can ignore brightness changes until the display
is drawn to. If UI side manages to draw while the display brightness
is still at zero level, the display backlight can stay powered off
until further changes on UI side happen.

Ensure that non-zero display brightness is already in place before
enabling display updates via compositor.

Also fix detection of already finished brightness fade.
Delay display on signal until unblank brightness fade is finished

When display is on signal is broadcast, a swarm of process wake up.
This makes the tail part of brightness fading jittery because mce
timers are not scheduled precisely enough.

Delay sending of display on signal until target wakeup brightness
level is reached.
Allow/deny brightness fading by type instead of current display state

Since display state no longer reaches on state before unblank fading
is finished, the ALS based brightness tuning is also delayed and the
display first wakes up to wrong brightness if lightning conditions
have changed during display off time.

Allow/deny brightness fading changes based on ongoing/requested
fade type instead of relying on current display state.

Use target stable display state for deciding whether ALS tuning should
be attempted or not. If the tuning happens before/during unblank fading,
adjust the fading target instead of starting longer ALS adjustment fade.
Add graph describing transitions done at display state machine

The state machine logic dealing with display state changes can be
a bit hard to follow. I've maintained a dot-file that visualizes
the state machine operation - off the mce source tree. Having it
in the same place as the state machine implementation would make
things easier for everybody.

Add the dot-language graph to mce source tree.
Do not block on <--> dimmed display state transitions due to fading

Delaying transition to or from dimmed state makes the event eater
misbehave - events can get through instead of bouncing the display
back to on state or get ignored when they should not be.

If the transition is being made from states where ui is expected
to be active, do not delay the display state transition due to
ongoing brightness fade.
Do not filter out activity when display is in dimmed state

Although it is normally not possible to have lock screen visible in
dimmed state, it could occur due to some timing glitch or explicit
request over D-Bus. And then user activity is ignored due to tklock
state, display does not bounce back to on state and after the event
eater gets disabled the user interface is active until blanking timer
turns the display off.

If display is in dimmed state, never ignore inactivity.

Also rearrange code to make it easier to see when inactivity timers,
activity callbacks and status change signals get handled.
Merge pull request #218 from spiiroin/jb21833_brightness_and_compositor

Tune brightness handling during display power up/down