Make unblank and unlock via double tap work again

Legacy option to allow bypassing of lockscreen with doubletap was
broken.

Make it work again.

Also do not use raw numeric values to evaluate doubletap_gesture_policy.

[mce] Make unblank and unlock via double tap work again
Add helper functions for setting up configuration change tracking

Having helper functions for both reading initial values and installing
change notifiers allows builtin-gconf value tracking setup to be more
compact and readable.
Rewrite powerkey handler to allow more flexible configuration

Taking double powerkey presses in use caused unconditional delay for
single press handling. The actions that could be configured to be taken
were not be differentiated based on display state, which made it
impossible do one thing from display off and another one from display on.
And since static configuration was used, changes did not take effect
without restarting mce.

Make possible actions as small and simple as possible. Allow combining
them freely to choose actions taken. Use separate action combinations
depending on whether display is on or off. Execute common parts of
single and double press actions immediately when 1st powerkey press
is released.

Allow more flexibility for using custom dbus actions by allowing user
configured method call to be made instead of signal broadcast.

Use dynamic runtime changeable settings instead of static configuration
from ini-files and add options to mcetool for changing all of them.

Use the new functionality to:
- apply device lock when double press is made from display on
- unblank and hide lockscreen when double press is made from display off

[mce] Rewrite powerkey handler to allow more flexible configuration. Fixes JB#23653
Re-evaluate autolock if device wakes up from suspend

When display is automatically dimmed and then blanked there is a 30 second
grace period before tklock gets applied. Since the device most likely
also suspends soon after blanking the screen and we do not want to wake
up just to toggle the tklock state, the end of grace period is evaluated
when display is about to be turned on. This can cause ipc timing problems
if powerkey/doubletap is configured also to remove the tklock.

Also do opportunistic grace period end detection if the device wakes up
from suspend due to reasons that would not cause the display to turn on.
This should make it less likely that both lock and unlock happen at the
same time.

[mce] Re-evaluate autolock if device wakes up from suspend
Do not broadcast intermediate tklock changes over D-Bus

If mce side state machines oscillate between tklock on and off, it
can cause problems due to ui side trying to react to intermediate
states.

Use idle callback to delay sending of tklock state information so that
only the final tklock state is communicated outside mce process. Hold
a wakelock until the dbus ipc is actually made plus couple of seconds
to make it more likely for ui side to have time to process the state
change before device is allowed to suspend.

Also clear last send state when tklock change requests are made over
D-Bus. This way the state mce arrived at is always broadcast even if
the request ends up getting ignored.

[mce] Do not broadcast intermediate tklock changes over D-Bus
Set tklock if devicelock gets applied immediately after unblanking

If device is suspended, device lock might get applied at unblank time.
This in turn can leave the previously used application visible and
usable.

While the ideal solution would be to use iphb timer for locking the
device while still suspended, using heuristics at least denies full
access to application content if delayed device locking happens.

[mce] Set tklock if devicelock gets applied immediately after unblanking
Merge pull request #221 from spiiroin/jb23653_rewrite_powerkey_handler

Rewrite powerkey handler to allow more flexible configuration