Summary:
There is a race condition in the following situation:

- Server creates a global
- Client binds to that global (making a new resource for that global)
Simultaneously:
- The client uses this resource
- The server deletes the global

We then process an event for a resource linked to a deleted global.

This is noted in the specification, the client documentation says:
"The object remains valid and requests to the object will be
ignored until the client destroys it, to avoid races between the global
going away and a client sending a request to it. "

KWayland does not handle this at all.

The global's user data refer to our C++ wrapper
The resource's user data refer to *the same* C++ wrapper

When the global is deleted the resource user data now refers to garbage.

To fix the issue, instead of setting the resource userdata to the
global, we set it to a smartpointer to the global stored on the heap.

We can then validate if our global is still valid.

Theoretically this applies to every global

Practically there are only 3 globals that don't have the lifespan of the
server. Output (which is read only and doesn't matter), Blur and
BackgroundContrast.

Blur resets it's global when a screen geometry changes.

Unfotunately this exactly at the same time that Plasmashell is
doing a lot of processing and creating some blurs.

Test Plan: See unit test

Reviewers: #plasma, graesslin

Reviewed By: #plasma, graesslin

Subscribers: graesslin, anthonyfieroni, plasma-devel, #frameworks

Tags: #frameworks, #plasma

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