Groundwork for wp_linux_explicit_synchronization

Created by: ascent12

Another entry in my series of massive PRs that I take too long to finish.

Groundwork needed for #894 (closed) Closes #1546 (closed)

Due to the very large amount of API breakage this introduces, I'd like to give people a heads up and get any feedback on the new design.

To see a full explanation for why I'm doing this, see the issues linked above. But to sum it up quickly:
Our current state-keeping method won't work for explicit-synchronization, since a surface being committed now doesn't really mean it's ready to be shown. Instead of just "pending" and "current", we have to keep a queue of commits, so that we always have a valid buffer handy.

The core part of this is wlr_commit. This represents a "coherent presentation" of the client's contents, and should contain all of the information to render a client correctly. Every bit of state synchronized by wl_surface.commit should be changed to use this.

Todo:

• wlr_compositor
• wlr_subcompositor
• wlr_xdg_shell and related (WIP)
• wlr_xdg_shell_v6 and related (There have been talks of removing this anyway)
• wlr_fullscreen_shell_v1
• wlr_layer_shell_v1
• xwm
• wlr_presentation_time
• wlr_linux_explicit_synchronization (Only acquire fences; maybe a different PR)
• wlr_buffer
• wlr_renderer
• wlr_seat and related (They set wlr_surface roles)
• wlr_pointer_constraints
• Other trivial uses of wlr_surface (e.g. wlr_output)
• tinywl
• rootston
• More comments and documentation

Extra notes:

• All wlr_surface functions are being merged into wlr_compositor. I haven't removed the old code yet, so I'm using a _2 suffix to just prevent some conflicts. That'll be removed eventually.
• wlr_region functions were merged into wlr_compositor.
• wlr_subcompositor was split out from wlr_compositor, technically making this an optional interface (but you'd want to use it)
• wlr_subcompositor is definitely the hardest part of this, because it's simply a complicated specification. Changing the other protocols will be much easier by comparison.
• I don't want wlr_surface managing any real buffer operations
  • wl_shm should be added to the renderer (using wlr_shm from another of my PRs)
  • Some callback functions to get information for a wlr_buffer would be needed, as they're needed for protocol compliance checks.
• I haven't done any real testing on a lot of the current code; more protocols need to be done before I can look at doing tinywl and rootston and giving it a real go. I've done some basic hack code to test the bare essentials, though.