So far kcheckpass allowed to try to verify one password. This required
kscreenlocker_greet to exec for every new entered password. Due to that
we cannot enable seccomp in kscreenlocker_greet.

This change prepares for supporting seccomp by making it possible to
have a long living kcheckpass with multiple authentications. For that
the interaction is changed:

• kcheckpass gets started without going into Authenticate directly
• kcheckpass uses a signalfd for waiting on sigusr1 and sigusr2
• kcheckpass goes into a loop for authentication
  • signals parent process through socket that it is ready for auth
  • waits for signal
  • on sigusr1 starts to authenticate
  • on sigusr2 goes out of loop
  • after authenticate goes into next loop run to continue

For the authenticator in kscreenlocker_greet the main change is to
send the signal to kcheckpass when it wants to authenticate.

In addition the authenticator supports both a delayed and a direct
mode. In the delayed case kcheckpass gets started directly on startup
for the long living process. In the direct mode it starts kcheckpass
when going into authenticate. We need both modes as kcheckpass is not
supposed to use the long living process when it is setuid root.

For the moment kscreenlocker_greet by default still uses the direct
interaction. This will change when seccomp integration is added.

The test application gained a new command line switch to use either
direct or delayed authentication.