render/pixman: avoid copy when creating textures

[emersion]

This allows the Pixman renderer to stop memcpy'ing textures.

• Address the shm client buffer SIGBUS issue

Depends on: #2851

cc @bl4ckb0ne

[emersion]

With this PR, the memcpy for client buffers is removed with the Pixman renderer. On my machine, CPU usage goes from 6% down to 3% when playing a fullscreen video.

[emersion]

The last commit contains an attempt at fixing the SIGBUS issue (see #2864). It adds guards to data ptr accesses to allow wl_shm_buffer to prevent compositor crashes. To test, start wlroots with the Pixman renderer and then run wleird's sigbus client.

Some questions:

• I'm not 100% happy with the additional state-tracking that wlr_buffer needs to do. OTOH, a more elaborate acquire/release mechanism would likely be over-engineering, and wl_shm_buffer offers the same {begin,end}_access API.
• Should the guard be separate from the data ptr attribute retrieval? e.g. have both functions in the API: wlr_buffer_get_data_ptr(buffer, &data, &format, &stride) + wlr_buffer_begin_data_ptr_access(buffer)
• Should we transition to a more mmap-like interface? e.g. wlr_buffer_map(buffer, &data, &format, &stride) + wlr_buffer_unmap(buffer, data) (implementations would be free to retain the same mapping under the hood). See also: gbm_bo_{map,unmap}.
• Name bikeshedding?

cc @bl4ckb0ne

[emersion]

Should the guard be separate from the data ptr attribute retrieval?

No: in the case of wl_shm_buffer, the data pointer is not static and may change if the client resizes the shm pool.

Should we transition to a more mmap-like interface?

We can't easily provide such an interface with wl_shm_buffer. We may be able to do it if we re-implement wl_shm.

[emersion]

This is now ready for review.