`users` and `who`: need to check the user's login shell is alive

While debugging tests for a pinky PR (#3155), I saw some inconsistent behavior between GNU's users and who utils vs. ours. The PR adds a fake entry to the system's utmp file, since the GitHub CI runner doesn't log in to any accounts, so pinky wasn't displaying anything during testing and letting bugs slip through. Once that was working, our versions of users and who started displaying the runner from the fake entry, but GNU's still does not. I ran strace on them on my local system, and noticed that the GNU versions call kill($PID, 0), where $PID is the PID of the login shell associated with that user. I suspect that the GNU versions aren't taking utmp at its word, and are checking the return value of this kill() call to double check that the user from the login entry is still running a login shell. The fake entry added in #3155 gives a fake, very high (and therefore unlikely to be used in the span of a GH CI run) PID, so the check fails for GNU, but looks fine to ours.

To fix this, we need to:

• make users check the login PID is still running
• make who check the login PID is still running
• re-enable any disabled tests from #3155
• add an additional fake utmp entry with PID 1 (i.e., a PID that should always exist)

The last step, adding the additional utmp entry, is necessary because without it, users and who are suffering from the same problem pinky was (no command output = behavior is mostly untested), but we can't just change the existing one lest this bug return.

Start with the users and who entry points and the utmp-based tests added or disabled for pinky PR #3155. Compare their behavior with GNU users and who, including the login-shell PID check described in the issue. Done means both commands ignore entries whose login PID is not running, re-enabled tests pass, and coverage includes fake utmp entries with an invalid PID and PID 1.