Update NEWS.

Fallout from commit d5552cc3.

If we're a Wayland compositor we shouldn't be taking this path, ever.

Don't overwrite the watch with a new malloc'd variable.

It should be META_TYPE_WAYLAND_STAGE, not META_WAYLAND_TYPE_STAGE.

Well, actually, it *should* be META_TYPE_NATIVE_STAGE, because it's
not related to Wayland at all. But that comes later :)

These are also used by the native manager.

While I'm here, I might as well. We rely on Xcursor now.

It seems the new automake likes to litter these files all around.

To stop automake from complaining

It's about generic display config, not XRandR specifically.

We'll use this to get the initialization between the Wayland and
X11 compositor codepaths back in sync.

It's about display servers, not Wayland integration.

Right now this just has all of the files in one directory. We'll
be introducing more structure to this in the future, and build
a proper backend system.

It makes our life so much easier.

We're going to make MetaCursorReference specialized and per-backend soon.

This will allow us to have a MetaCursorReference 'subclass' that's
lazily loaded. We currently always load all the images.

The long-term plan is to have a subclass for each "backend" and only
have CoglTexture as a common denominator. For the nested X11 backend,
we use XDefineCursor on our stage window. For the Wayland backend, we
would use set_cursor on our stage surface. For the native backend, we
would use the GBM code that's there right now.

The CoglTexture is there to be a "shared fallback" between all devices,
and also for the get_sprite API.

The odd man out is the X11 compositor case. For that, we need to move
the responsibility of setting the final cursor image out of
MetaCursorTracker, and simply have it be about tracking the used sprite
image and pointer position.

This is really an X11 front-end thing, so it doesn't belong in the
cursor tracker, which is a back-end thing.