init: reboot: Improve RebootMonitorThread() evasive actions

Currently the RebootMonitorThread() will wait for the full timeout to
occur and then will take "evasive actions". This means:
* On debug builds, execute SysRq-L and SysRq-W do dump some info.
* If shutdown (or thermal shutdown), use SysRq-S and SysRq-U to try to
  preserve data.
* If shutdown (or thermal shutdown), tell the kernel to shutdown.
* Otherwise, execute SysRq-C to trigger a crash/reboot, which should
  be classified as a kernel crash.

There are a few problems here:
1. There is no indication if we're getting close to triggering the
   evasive actions. It's nice to have a "bark" type warning before a
   "bite" of a watchdog.
2. The SysRq-S and SysRq-U that were used to try to preserve data were
   likely not effective. Both of these SysRqs are non-blocking, so
   while we might have kicked off the actions we didn't let them
   finish.
3. We only try to sync data to disk in the case of shutdown, not
   reboot. Syncing data to disk should be as relevant for the reboot
   case.

Improve RebootMonitorThread()'s evasive actions by breaking the delay
up into 10 steps. Between each step print a warning to the logs.
Trigger SysRq-S (sync) after the first 8 sleeps. Trigger SysRq-U
(remount r/o) after the 9th sleep. This is a bit of an arbitrary
heuristic chosen because:
* We want lots of time to sync. The timeout here is supposed to be
  fairly large, so even if 1/10th of it is done it still seems time to
  think about syncing. There shouldn't be any harm in syncing multiple
  times. Another advantage of "sync early, sync often" is that if the
  user gives up and tries to force a poweroff while we're still
  waiting we will have already tried some syncing.
* We don't want to force remount to read-only until we've pretty much
  given up but we still want _some_ amount of time for the remount to
  take effect.

As a side effect of this, the "SysRq-L" and "SysRq-W" on debug builds
now happens after the Sync/Remount, but that shouldn't be a problem.

Bug: 409835922
Test: Set the delay to 59 seconds and see it bumped up to 60.
Test: Hack in delays and see the syncs/unmounts and eventual timeout
Change-Id: I6e5dbc70de3007861b3c720ff26b296e1447c089