Abstract the backend interface away

Remove the fixed calls into the udev backend and provide a basic interface
instead that allows other backends to hook into device/seat creation. This
enables multiple backends, specifically a path-based backend that is needed
for X.Org drivers.

This patch should have no visible functional changes.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
udev: Refcount the seat for each device

Use the seat's internal refcounting to up the reference each time we have a
device using it. This fixes the issue with seats being created but never
actually removed by anything.

udev_seat_get_named() will now return a seat with refcount 1 for a newly
created seat, or just up the refcount for the seat if it already exists.

This requires that the ADDED_SEAT and REMOVED_SEAT events up the refcount of
the seat as well: a device may be removed before the event is processed,
without the refcount the seat would be destroyed (if it's the last device on
the seat).

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
udev: notify about a removed seat when the last device is removed

When the last device is removed from a seat, destroy the seat.
This guarantees seat removal events on libinput_suspend() as well.

Note that the seat must be manually unlinked, we can't rely on the unlinking
in libinput_seat_destroy. After the event, the seat's refcount is always > 1,
so the seat will live on until the event is destroyed. We need to make sure
it's not in the list anymore though.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Suspend libinput before destroying it

libinput_suspend() already causes the fds to be closed, devices and seats to
be removed, etc. Call it before libinput_destroy() to reduce the
backend-specific code.

No real functional change, the udev backend already did this anyway.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add libinput_create_from_path

Hooking libinput up to udev isn't always possible, especially if libinput were
to be used in the X server which already has the udev handling built-in.
Add an option to create a context from a path.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Drop capability events

We don't really support devices changing capabilities at runtime. The kernel
has no ability to tell us when this happens on an already-opened device and
the few devices that can literally change physical capabilities (e.g. the
wiimote) open up extra kernel devices instead of modifying the existing one.

Thus, we don't need to notify about devices changing capabilities.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>