Behavioral changes/fixes:

- Whitespace skipping now is performed in all appropriate places.
- Visual skipping now happens on the same set of visual names.
- Quoted arguments in commands now work. In fact, so do all other shell
  characters.

One remaining difference though (intentional):

- The program name itself can't be quoted.

This serves to handle cases such as PAM asking the user to authenticate
to an external device by asking the user to do something with
PAM_TEXT_INFO then waiting for the user to do so; we then want to keep
PAM's message on the screen until the action happens.

Of course, we still do show the processing message if the last action
was an entry dialog (e.g. password entry).

Also changes on some systems the events on bad password entry:

- Before: Password:, Processing..., Invalid Password, Processing... (sleeping 2 seconds)
- After: Password:, Processing..., Invalid Password (sleeping 2 seconds)

This gives users more time to read the error message.

Yes, this means auth_pam_x11 may instant time out when the clock is
stepped forward by NTP. Trying this out anyway, as:

- This should only be an issue if the clock is stepped forward by more
  than few minutes, as the timeout defaults to 5 minutes.
- We also put in a specific counter measure against the clock stepping
  backwards - when it does, we simply reset the timeout.

Advantage: that way, auth_pam_x11 will almost always exit on resuming
from suspend state. This is very desirable so we can control visibility
of the hostname in a wrapper script.

Now that it's 1px smaller from all sides, not only should it not cause
unredirecting (and thus unmapping of the COW) anymore - even better,
it's forced to be above everything else, so it can even prevent
unredirecting in case a full-screen application is running, and thus
makes sure that the COW stays alive.

I need it for my Bspwm setup ;)

- Work around Bspwm issue by explicitly never unmapping Bspwm-owned
  windows. Also remove incompatibility note about it.

- Don't unmap windows owned by this process.

- When detecting an xsecurelock-owned window that's not of the same
  process, disable forcing to prevent harm from the screen already being
  locked.

The option is quite intrusive, and the documentation states "use with care", so I think it makes sense to default it to off.

It's now hidden behind a #define that's not enabled by default.

It simply shouldn't be necessary unless there are driver bugs, and given
auth_pam_x11 draws at low fps it's not very effective at hiding
information leaks (like the one we discovered recently involving
Cinnamon crashing) anyway. On the other hand it may use quite a lot of
CPU power, especially on low-end systems.

Effectively reverts 6b1b4f4e.

XSECURELOCK_FORCE_GRAB=1: locate all client windows, hide them, grab,
unhide them. Will very likely rearrange them, but otherwise works with
most WMs.

XSECURELOCK_FORCE_GRAB=2: locate all windows below the root window, hide
them, grab, unhide them. Will solve some cases =1 does not, but probably
breaks most WMs.

When reinstating grabs isn't enabled (it's currently hardcoded on), still do retry every frame if it failed.

It's only meant as a fallback in case of compositor misbehavior, and
making it smaller adds compatibility with Cinnamon's compositor
(Muffin), which will then no longer unredirect in response to
xsecurelock starting.

Mitigates possibly visible screen content in case a compositor drew on
our window.

Note that we're not just using XClearWindow as this would clear more
stuff before we're writing, thereby increasing flicker - instead, we
clear the area we've not drawn on when we're done drawing.

Also:

- Grab on the root window, not the parent window (fixes losing grabs
  when the compositor restarts).
- Log when raising above another window.
- Reorder tests for windows in events in a consistent order (namely
  inverse creation order).

Also, make it white so I can see when it becomes visible (it should
never unless something goes wrong).

It's meant to guard against compositors giving up compositing and
releasing their window, as it'll then ensure there's still _something_
on top of the desktop.

This shouldn't be able to do any harm - but nevertheless let's evaluate
this properly yet as I have no reproduction case for this problem yet.

whoops :/