This is intended as replacement for the NotifyFoo methods. libei
provides a more flexible and powerful method of sending input events to
the compositor.

A new method ConnectToEIS requests a file descriptor from the compositor
which can then be plugged into libei.

Once established, the communication between compositor and application
is direct, without the need to go through the portal process(es).

To avoid ambiguities between NotifyFoo and input events sent via libei,
any application that uses an EIS connection may not use the NotifyFoo
methods.

Co-authored-by: Olivier Fourdan <[email protected]>

This portal is aimed at allowing applications to capture input from
physical devices, the prime use case is the server component of an
InputLeap (a Synergy fork) setup where local devices are used to control
a remote display.

The general flow for the InputCapture session is:
- application queries the "zones" available (usually representing the
  desktop)
- application sets up "pointer barriers"
- application provides a libei-compatible handle for the actual input
  events
- when a cursor moves against/across a pointer barrier, the compositor
  notifies the client and re-routes input events from libinput to libei
  instead of controlling the local cursor

Notable: the actual input events are not part of the portal here,
they're handled by the direct libei connection between compositor and
application. This portal has no direct dependencies on libei itself.

The compositor is in charge of everything - it can restrict some screens
from showing up in the regions, it can deny pointer barriers at
locations, it decides when a pointer barrier is crossed, it can stop
capturing (or filter events) at any time, etc.

This allows an application to effectively say "start capturing now" once
it calls Enable at some later point. The trigger is separate from the
Enable call to a) make it more obvious that is what we want and b) allow
for user interaction if need be. The process thus is:

-> CreateSession
  <- session handle
-> SetEnableTrigger
  <- compositor says yes
-> Enable
  <- compositor says Activated
  <- captured input flows

As with pointer barriers, the exact conditions for enabling the session
are compositor implementation details but one would expect that having
focus is a base requirement.

In the Activated/Deactivated case, the capture session effectively
remains. Where the session is Disabled (by compositor or application,
e.g. on focus out) the application can immediately call SetEnableTrigger
+ Enable to get capture going again whenever it's convenient (e.g. on
focus in).

Unlike pointer barriers, zones do not apply for this case.

This requires an active GlobalShortcuts session with the requested
shortcut(s) to be active - this call re-uses the shortcut ids from that
session.

When the input capture session is enabled and the compositor deems
the shortcut to be triggered, capture starts.