Replace protobuf with a wayland-like protocol

This patchset replaces the ad-hoc protobuf-based protocol with something that is closely aligned with wayland. The wire format header is slightly different (see proto/protocol.xml) but otherwise the principle is the same. The various bits are now split up across multiple interfaces, so for the usual cases we will have something like this hierarchy:

• ei_connection
  • ei_seat
    • ei_device
      • ei_pointer
      • ei_keyboard
    • ei_device
      • ei_touchscreen

A quite different approach is the initial connection - this is handled by a handover object, the ei_connection_setup. Notably, a client declares the various supported interfaces and their versions before sending ei_connection_setup.done. The EIS implementation then replies with the ei_connection_setup.connection() event which has the ei_connection object in a version both support (in wayland this would be the wl_display object). This allows us to update the main object over time.

Except for the (currently mostly unused) ei_callback interface all our objects are created server-side and sent as events, so e.g. ei_connection.seat() gives the client an ei_seat object, ei_seat.device() gives the client a new device. There's no registry like in wayland.

Code generation is via scanner.py which takes the protocol.xml and passes it to a jinja template. The generated C code is quite specific to libei/libeis, the scanner itself would be generically usable though.

The implementation is... functional. The test suite still passes so libei and libeis can still correctly talk to each other. The public API has not changed.

There's a new test suite that speaks the protocol directly to test the EIS implementation (python code generated via scanner + templates). In theory that one can test other implementations too (you may eventually be able to run that test suite against any EIS implementation) but that's not really tested yet. Because the protocol handling changed a lot, there's going to be a lot of niche bugs to do with clients sending invalid sequences of requests, they need to be fixed one by one.

But for now, I'm at the point where rebasing this takes more time than building on top.

I'd appreciate any high-level comments on the protocol in particular since that is the crucial part here, the rest is just implementation. And any show-stoppers like race-conditions etc that we already know of in wayland but I forgot about or am not aware of 😄

Fixes #25 (closed), #4 (closed)

cc @jadahl, @ofourdan, @emersion