power: Fix what seems to be a c&p typo

The check to inhibit the lid close action when there's external monitors was
quitting after the first run, even though it announces it will check again later.

https://bugzilla.gnome.org/show_bug.cgi?id=719975
power: Fix restarting of the lid inhibitor check timer

We were trying to restart the timer when randr events tell us that
there are no longer any external monitors connected. But we were only
actually restarting if there was a timer scheduled already, i.e. in
case that there was no previous timer we wouldn't start a new one
either and thus we'd never clear the inhibitor. This would happen
when closing the lid, since we'd stop the timer on
do_lid_closed_action().

This commit simplifies the logic and makes the timer be one shot again
as was intended in 1e14c67 .

The logic now is:

1. Only take the inhibitor and start the timer on randr events,
   unconditionally. If there was a timer running from a previous randr
   event we stop it and start a new one so that the "grace period" is
   always counted since the last randr event.

2. On the timer callback we check whether we should keep the inhibitor
   and thus we either suspend at that point or don't. In any case, we
   stop checking until we have further randr events.

3. When the lid closes, we only have to check if we should lock the
   session. If the timer has elapsed already and we should suspend,
   then the inhibitor is already gone and logind starts suspending
   right away. Otherwise we suspend when the timer elapses and we
   remove the inhibitor, unless we see an external monitor at that
   point.

https://bugzilla.gnome.org/show_bug.cgi?id=729331
power: Cancelling a temporary unidle shouldn't set an idle mode

The caller already knows which idle mode it wants us to move to.

Automatically going back to the previous idle mode here would at best
cause a quick spurious idle mode switch which would be immediately
overriden by the caller or, at worst, we could go into suspend if the
previously saved mode was SLEEP.

The latter could happen on resume from suspend because there's a race
between idle_became_active_cb() and handle_wake_up_screen(). If the
second wins the race then we'd set a teporary unidle with the previous
mode being SLEEP, meaning that when idle_became_active_cb() cancels
the temporary unidle afterwards we'd immediately move to SLEEP again.

https://bugzilla.gnome.org/show_bug.cgi?id=729024