(Maint) Retry shutdown abort command

Many of the acceptance tests execute puppet to trigger a reboot, and
then verify that the reboot was initiated. The tests do so by executing
the `shutdown /a` command to abort the shutdown. It returns 0 if a
shutdown is in progress, or 1116 if a shutdown is not in progress.

Note due to ruby bug[1], the exit code 1116 is truncated to one byte,
which yields 92.

However, puppet executes the watcher process asynchronously, so it was
possible for the acceptance test to issue the abort shutdown command
before the watcher process had initiated the shutdown. The tests tried
to work around this by sleeping for 5 seconds, but this doesn't work
on slow systems in CI.

This commit adds a helper method for retrying the shutdown abort command
and updates the various acceptance tests to use it. It also adds a
helper method for the opposite case, when verifying that a shutdown has
NOT been initiated.

[1] https://bugs.ruby-lang.org/issues/8083
(Maint) Handle race when puppet has already exited

Previously, if the watcher's call to `OpenProcess` failed, we treated
that as a fatal error, since we couldn't get a handle on which to
wait for puppet to exit.

However, if puppet exits before the watcher process calls `OpenProcess`,
then the call to `OpenProcess` will fail, and the watcher would never
reboot the system.

This commit checks that if `OpenProcess` fails and `GetLastError`
returns 87 (INVALID_PARAMTER), then it means the pid no longer exists.
And we can conclude that puppet has already exited (as opposed to being
a bogus pid), because puppet passes its pid as a command line
argument to the watcher.

If `OpenProcess` fails and `GetLastError` is something other than 87,
then that is still treated as a fatal error.