Replace wlr_client_buffer with wlr_surface_texture

wlr_client_buffer has a bad design: just because it needs some ref'counting functionality, it's implemented as a wlr_buffer. Its purpose is to allow compositors to obtain a frozen wlr_texture to keep painting an old representation of the surface for an arbitrary amount of time (e.g. during layout reconfigurations).

However a wlr_buffer lock means something else entirely, and abusing it for ref'counting a texture leads to various issues. In particular, wlr_surface checks the wlr_client_buffer lock count to decide whether to mutate a texture on commit. This falls apart if the buffer is locked for another purpose than freezing a surface texture (e.g. locked by another wlroots helper). Additionally, wlr_client_buffer forces backends to re-import and re-check the buffer each time the client commits, since DMA-BUF wlr_client_buffers are destroyed and re-created on each commit. wlr_client_buffer also doesn't properly forward all wlr_buffer operations to the source buffer: some are unimplemented, and the source buffer is not locked by wlr_client_buffer thus may be destroyed anytime.

To fix all of this mess, introduce a new struct wlr_surface_texture whose purpose is just to ref'count wlr_texture. Compositors can reference the texture to freeze it. The wlr_buffer can be accessed at commit time from wlr_surface.current.buffer.

TODO: currently this causes a perf regression in wlr_scene, since the scene is no longer able to extract a texture from the wlr_client_buffer, and thus unnecessarily re-uploads it on each client commit.

TODO: find a better name.

Future plans: expose this as a stand-alone helper so that compositors have control over texture upload.