It's sad that this is required, but some XScreenSaver hacks cause
XSecureLock to lose the grab on MotionNotify.

These can be overridden via:
- ./configure --with-default-auth-module=... --with-default-saver-module=...
- $XSECURELOCK_AUTH and $XSECURELOCK_SAVER environment variables
- Command line arguments (which work exactly as before)

Previously, the xset command sometimes got killed in response to
ScreenSaverNotify.

Instead, raise on VisibilityNotify. This makes sure possible email
notifications or other stuff show up as shortly as possible.

Quotes are required there...

Also, some minor changes done while auditing during documenting,
including fixes for:

- A file descriptor leak in the auth child (may DoS the screen).
- A race condition between querying display size and creating the
  window.

The saver itself then will use a subwindow of the grab_window. End
result: in case the saver calls XUngrabKeyboard on the window it's told,
it no longer will stop our grab. The "bumps" XScreenSaver hack does
exactly this.

With this, I also could remove the previously existing hack to reinstate
the grab every 100ms.

This makes the behavior of pressing a key while the saver is running
more intuitive.

Sorry for that. After this, unlocking properly authenticates again.

Use this if you for some reason can't use PAM.

This will ask for a new password if the user's password has expired
before unlocking.

As with XScreenSaver, checking for its return value needs to be
explicitly enabled via --enable-pam-check-account-type.

A random byte in memory was set to 0 in auth_pam_x11, and the password
possibly not zero terminated.

Thanks, Coverity!

Usage: --with-pam-service-name=xscreensaver.

This partially mitigates leakage of passwords to swap.

Note that information about the password from the X11 event queue, as
well as leakage on suspend-to-disk, may still be leaked.

Document the reasons why we don't endless loop here, as this password
buffer code may otherwise be too hard to follow.