Add Fill function to device-independent 2D acceleration interface

This patch adds a fill function to the device-independent blt2d_i
structure in interfaces.h. In the CPU backend, the fill function
is initialized with noop. In the G2D backend, the fill function
is initialized with the G2D fill function. In the sunxi G2D backend
(sunxi_disp.c), add a G2D fill function that supports both 16bpp
and 32bpp. In the X driver (sunxi_x_g2d.c), the private fill
function is initialized with the blt2d fill function. It not used
yet.
Add X driver PolyFillRect acceleration

Add fill acceleration to the X driver (sunxi_x_g2d.c) by hooking
PolyFillRect. It uses the fill function from the blt2d structure;
if this returns 0, it falls back to pixman or xorg fb. The
PolyFillRect implementation is based on xorg fb.

On the Allwinner A10 with G2D enabled, G2D fills may be slower
than CPU especially at 16bpp. The blt2d fill function can return 0
in this case or depending on other constraints. However,
accelerated fills do help CPU utilization.

This feature will be usable in other devices where accelerated
fill is not slower than CPU.
Implement "double speed" G2D 16bpp fills

In the sunxi G2D fill implementation, for 16bpp split fills in up
to three segments, using 32-bit fill for the aligned middle part.
Due to pixel clock limitations of the G2D engine, this is
significantly faster for large rectangles.

Benchmark:

1920x1080x16bpp@60Hz, ShadowFB disabled:

x11perf -rect500
G2D disabled:
 100000 trep @   0.4674 msec (  2140.0/sec): 500x500 rectangle (CPU 100%)
Before (G2D enabled):
  20000 trep @   1.3320 msec (   751.0/sec): 500x500 rectangle (CPU ~0%)
After (G2D enabled):
  35000 trep @   0.7956 msec (  1260.0/sec): 500x500 rectangle (CPU ~0%)

CPU fill is still clearly faster, even with this optimization. The benefit
is CPU utilization.