buffer: wlr_buffer_impl.get_data_ptr limitations

[emersion]

We've introduced wlr_buffer_impl.get_data_ptr for the purposes of the Pixman renderer. This works well enough but has some limitations:

1. The caller has no easy way to figure out the format in which pixels are laid out: Pixman renderer #2661 (comment). We've worked around this in the Pixman renderer by calling get_dmabuf/get_shm just to get the format.
2. It's not possible to safely wrap client wl_shm buffers inside a wlr_buffer. The commit "buffer: introduce wlr_shm_client_buffer" in Cache and re-use DMA-BUF textures #2851 does it anyways, but doesn't call wl_shm_buffer_begin_access nor wl_shm_buffer_end_access. Calling these before and after any access to the buffer data is necessary to prevent clients from SIGBUS'ing the compositor (by truncating their mmap'ed shm file). Wrapping a wl_shm client buffer in a wlr_buffer is desirable for screencopy purposes and for improving our buffer handling which is currently GL-centric.

cc @bl4ckb0ne

[emersion]

Some previous thoughts on the matter: #2399 (comment)

[emersion]

(1) has been addressed in #2894. (2) remains.