Use seccomp for implementing a sandbox for kscreenlocker_greet

Summary:
This change introduces a new optional dependency on libseccomp.
Libseccomp allows to forbid syscalls. With that we can constrain the
user defined dynamically loaded QtQuick code from the look'n'feel
package and from the wallpaper package. The idea is to protect against
"malicious" packages the user manually installed.

With the installed seccomp filter we can ensure that the QtQuick code
cannot perform the following operations:

• send password into Internet through forbidding the socket syscall
• use KIO to send password into Internet through forbidding fork+exec
• write password into a file through forbidding opening a file in write mode or creating a new file
• send password to another process through forbidding pipe/pipe2

So far our QtQuick code was already constrained by disallowing network
access through injecting a QNetworkAccessManager which forbids internet
access. But this was easy to circumvent through e.g. KIO.

The seccomp filter cannot protect against a malicious process already
running on the system. The obvious way to get out of this sandbox is
DBus. DBus is allowed in the sandbox, thus it is possible for a malicious
look'n'feel package to communicate with a running malicious application
through DBus. To protect DBus we need to implement an additional apparmor
profile.

The seccomp filter gets only installed if the seccomp dependency is
available and kcheckpass is not setuid. This is ensured with a runtime
check. For kscreenlocker_greet the main change is that when seccomp is
enabled the delayed kcheckpass authentication method is used.

Test Plan:
Manual testing and a new auto test which verifies the
restricted conditions.

Reviewers: Plasma

Subscribers: plasma-devel

Tags: Plasma

Differential Revision: https://phabricator.kde.org/D5029