Add screencopy protocol

[Drakulix]

Potential replacement for the quite simplistic and error-prone export_dmabuf protocol. Based on ext-screencopy.

• Allocates buffers on the client side to allow for proper modifier negotiation, resource attribution and also protecting the compositors buffers. This means the portal will have to use the gbm-api for allocation, we have to see how well that works out on nvidia's drivers.
• As an optimization allows client to only copy damage and to wait on damage, effectively limiting framerate to the targets framerate. This avoids unnecessary captures. Damage can be easily tracked separately for different sessions in the compositor to optimize rendering/copying.
• Supports capturing cursors separately for pipewire's metadata cursor mode

[ids1024]

Assuming a version of ext-screencopy is eventually accepted upstream, could we use that, but have own own non-standard interface/global that just provides capture_toplevel() and capture_workspace(), returning the same type of frame object? To stick as close to standard protocols as possible.

(Doesn't really matter now since the current version of ext-screencopy probably isn't quite what will be accepted anyway.)

[Drakulix]

Assuming a version of ext-screencopy is eventually accepted upstream, could we use that, but have own own non-standard interface/global that just provides capture_toplevel() and capture_workspace(), returning the same type of frame object? To stick as close to standard protocols as possible.

(Doesn't really matter now since the current version of ext-screencopy probably isn't quite what will be accepted anyway.)

There are a few examples of "extension"-protocols, that hook into an existing protocol and re-use it's types. E.g. we could keep the zcosmic_screencopy_manager and just let the capture_toplevel/workspace requests return an ext_screencopy_surface (or whatever that ends up being called).

Which is also why for all protocols we are currently building custom versions of, I tried to address all remaining review-comments before adjusting them for our needs to anticipate any further changes to the final version.

So yes, that is the idea and we will see if that works out.