Revert "[xlib] Fast-path the likely case of retrieving a known xrender_format"

This reverts commit 09a2b2ed3189fe12483cbd673c24ceddc2c20f3f.

Back in 2009, _cairo_xlib_display_get_xrender_format() had to acquire a lock to
do its job. The above commit added a fast-path which avoided the lock in most
cases.

However, in 2010 commit f74ad37e66bbdcc4d727ed6d931dde870d84c2f4 modified the
locking in the cairo-xlib backend and now this function never takes any locks.

Thus, the fast-path that was added a year earlier now just does the same thing
that the regular code does and the list of cached formats was checked twice.
Reverting the earlier commit fixes this.

Signed-off-by: Uli Schlachter <psychon@znc.in>
cairo-xlib: Fix out of bounds array access in format cache

The cairo-xlib backend maintains a mapping form cairo_format_t to xrender
formats. This is done via an array. The size of this array is
CAIRO_FORMAT_RGB16_565 + 1 which evaluates to 5.

However, CAIRO_FORMAT_RGB30 has the numeric value 5, too. Thus, using this value
as an index into the array would actually read the following force_precision
field from cairo_xlib_display_t.

This could be triggered by passing CAIRO_FORMAT_RGB30 to
_cairo_xlib_display_get_xrender_format(). From a quick look, I didn't find any
code which would allow doing this, but neither did I find anything allowing
CAIRO_FORMAT_RGB16_565, so it's better to handle this correctly than assert()ing
for this to never happen.

Signed-off-by: Uli Schlachter <psychon@znc.in>