RFC RE: wayland-server direction to depend on kwin internals

wayland-server is moving to depend on kwin internals in the Output and KeyState change refactors. The intention is solid and clearly has benefits, but I have a few minor concerns that I think we can address.

I definitely like many aspects:

• getting rid of pointlessly duplicated data types
• getting rid of the additional cache of data so we just have one source of truth

But I don't like:

• Losing encapsulation; we don't want some hypothetical future patch having TabletInterface trying to peek into the overview effect. Having things forced can avoid future spaghetti.
• Throwing away working unit tests in favour of only integration tests which can be difficult to implement
• Blocking future other kde wayland server projects - like the plasmashell as a nested compostior work from years ago Currently we could do that if we still export kwaylandserver from the kwin repo
• Potentially losing things like renderingservertest.cpp which have proved very useful in client debugging even recently where reduced complexity makes life easier.

So as a counter-propoal:

We introduce a new library "kwincore" (or whatever name) This contains all enums we want to share, and pure virtual classes like:

class KeyStateProvider : public QObject
{
    enum KeyState {blah blah}
    virtual KeyState keyState() = 0
    Q_SIGNALS:
        void keyStateChanged();
}

Then obviously kwin changes to

class InputRedirection: public QObject, public KeyStateProvider
{
};

but absolutely no other changes other than adding "override" somewhere.

And the same for abstractClient (for plasmawindowprotocol), virtual dekstops, and whatever else we have planned.

Xaver's Output patch is already effectively in this direction. Output is mostly a virtual base and FakeOutput works really quite nicely. We're just missing that last-mile to commit to having a universal design documented.