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.
Delay tklock broadcasting

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.

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.