Add unstable dmabuf-pool API

[zdobersek]

Introduce wpe_view_backend_dmabuf_pool_fdo, a wpe_view_backend extension that
demands manual dmabuf managemenet from the user.

This approach to buffer management allows for most flexibility in terms of what
kind of dmabuf objects should be used for rendering. It allows for user to
specify in detail the format, multi-planarity and modifier data of the dmabuf
object.

In order to work with such dmabuf objects, the renderer_backend_egl interfaces
have to leverage a new WS::EGLClient implementation that uses custom Wayland
protocols to properly handle dmabuf content across process boundaries. To
correctly render into these objects, we have to leverage the surfaceless EGL
platform, along with importing the dmabuf objects into EGLImages that we then
use as backing resources for renderbuffers used to render a given frame.

For each wpe_view_backend_dmabuf_pool_fdo, the related client (managed by the
user) has to provide callback implementations that handle dmabuf pool entry
management as well as the notification of which dmabuf pool entry has been
committed for display as the content of the related view.

Upon the create_entry callback dispatch on the client, the callback (as provided
by the user) has to return a wpe_dmabuf_pool_entry object that was initialized
with the relevant dmabuf data. Upon the destroy_entry callback dispatch, the
specified object has to be destroyed.

The commit_entry callback dispatch on the client specifies which dmabuf object
should be presented on the screen, containing the most-recent composition of the
corresponding view's content.

The dmabuf pool entry allocations and deallocations are relayed from the
renderer_backend_target_egl implementation. Whenever a new buffer is required
for rendering, the renderer_backend_target_egl will request for a pool entry to
be created, getting back the relevant dmabuf information and spawning necessary
GL resources that are needed to render into that dmabuf. When finished, the
pool entry will be committed, leaving it up to the user to handle the pool entry
as required.

TODO:

• TargetDmabufPool: cleanup
• TargetDmabufPool: resizing support

[aperezdc]

I've had this half-reviewed in a tab for weeks, sorry about the delay!

Functionality-wise patch looks fine to me, with a few nits. Something I would like to start doing is documentation with every commit that adds API. We have scaffolding in place for that, and in this particular patch we could really use a copy of the buffer lifetime notes from the commit log saved to a Markdown file e.g. docs/dmabufpool.markdown, and that file listed in docs/sitemap.txt.

[aperezdc]

This PR needs a rebase. Do we still want to try and merge this before branching for 1.10.x?

[zdobersek]

I would say yes, in current unstable alignment.

[aperezdc]

I have been trying this over the last few days and it is working as expected. I am going to merge it later today or tomorrow, unless somebody opposes, then branch for 1.10.x and put out a 1.9.90 release 😃

[aperezdc]

The WPE_CHECK_VERSION conditional here means that when building with an older libwpe the ::deinitialize() method will never get called, and we would leak resources.

Wouldn't it make sense to only compile the whole DMA-BUF pool support when building againsy libwpe≥1.9.1?

[aperezdc]

@zdobersek, I have one last doubt before merging this, please check my comment about the version check for libwpe≥1.9.1

[aperezdc]

After a chat with @zdobersek today we have agreed to slate this for 1.12.x, so I have changed the milestone accordingly.