Figure out how to make ext-session-lock safer

The ext-session-lock protocol only allows a single surface to be displayed on the screen (and possibly/optionally privileged surfaces like an IM or shell surfaces). This makes it hard to implement an unlock dialog using a toolkit, because that has to be done in-process with the screen locker, which isn't particularly safe (toolkits can crash!).

Fortunately the ext-session-lock protocol specifies that if the locker client dies while the session is locked, the compositor should keep the session locked, even if that means it will be impossible to unlock it.

That's great, but the latter bit sucks.

Ideas: When the locker client starts using the protocol to lock the screen, check its PID and figure out the path to its binary. If it later crashes and restarts, and tries to re-lock the screen, check the binary path, and if it matches, allow it. Otherwise, don't, and remain locked.

The sysinfo crate can help getting the path to an exe on linux, android, macos, and freebsd. Seems like solaris/illumos uses /proc/$PID/path/a.out, so that's an easy thing to implement. openbsd seems to intentionally not make this sort of thing available.

Turns out lsof can get the exe path (txt in the FD column, REG in the TYPE column, read the value in the NAME column), though not sure if that works on openbsd. On systems where we can't get this information, we can fall back to just keeping the screen locked forever. Or perhaps I could put up my own unlock dialog from the GTK UI thread in that case.

(Which also makes me think.... maybe I should move the UI thread to another process... it would be safer.)