Remove dmabuf synchronization code

This has no effect on the current setup. The kernel does not have
the dmabuf fences/poll support, and GEM does not have the fsync op
implemented required for msync() to have an effect.
Synchronize texture access with umplock

Via DRI2 CreateBuffers we give the underlying pixmap memory addresses
to Mali. Both Mali and X then access the pixmaps, so we have a
synchronization problem to solve.

Fortunately, libMali can be built with "umplock" functionality,
which basically (hopefully) means that Mali informs the kernel when
it is using a specific texture. We can then use umplock here too,
in order to guarantee synchronized access.
Create cacheable offscreen pixmaps, sync caches with UMP

This enables the CPU cache for offscreen pximaps, a performance increase.

But we must then flush caches in the right places.
We do not worry about the Mali GPU L2 cache here, this does not seem
necessary, maybe Mali itself handles that.

What we do have to worry about is handling the CPU cache for offscreen
pixmaps. Before accessing pixmaps from the CPU, we should invalidate the
CPU cache. And when later returning pixmaps back to the GPU, we should
flush the CPU cache.

While the CPU is using the data, we also need to ensure exclusive
access, otherwise rendering oddities occur when the GPU is accessing
the data at the same time. umplock, with a libMali also built with
umplock support, lets us implement this synchronization with ease.

Scanout buffers are left as writecombining. I'm not sure where the
appropriate write-combining-buffer flush happens, if at all, but this
seems to be working as-is.