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