Summary:
The current KScreenLocker expects the Compositor to hand over the
KWayland::Server::Display pointer.

This has several disadvantages:
* In KScreenLocker functionality is duplicated which the compositor
  probably has setup already (creating client connections manually).
* The Display object has a way larger scope than what KScreenLocker
  actually needs.
* Ownership of the Display is unclear in regards to memory but also
  what the compositor is still allowed to do in comparision to KScreenLocker
  with the Display.
* KScreenLocker can only be integrated in compositors using KWayland for
  managing their wl_display protocol object.

Instead it is now enough to hand over a single file descriptor KScreenLocker
can use as its client endpoint to talk to the compositor.

Test Plan: Manually in Wayland session, autotest.

Reviewers: #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: apol

Differential Revision: https:/...