Drop unneed g_type_init calls

We have been requiring a new-enough GLib for a while now,
so drop this unnecessary clutter.
Port gdk_pixbuf_new_from_stream_[at_scale_]async to GTask

https://bugzilla.gnome.org/show_bug.cgi?id=712704
Port gdk_pixbuf_save_to_stream_async to GTask

https://bugzilla.gnome.org/show_bug.cgi?id=712704
Make scaling of xpms work again

Commit c62676a284 had an unintended side-effect for loaders
which omit to call size_func, the new size set by
gdk_pixbuf_loader_set_size would overwrite the original
pixbuf size, and in effect force a scale factor of 1.0.
The xpm loader is one of the few which omit the size_func
call, thus the regression that calling
gdk_pixbuf_new_from_file_at_scale does not scale xpms anymore.
The fix is to use separate variables to pass the dimensions
when calling the size_func on behalf of the loader.

https://bugzilla.gnome.org/show_bug.cgi?id=686514
Add tests for scaling of various image types

Notably, this test catches the regression fixed
in the previous commit.
Trivial typo fixes
Make some string data const

https://bugzilla.gnome.org/show_bug.cgi?id=144042
Remove an outdated comment

We're now marking the tiff loader as threadsafe, so
remove the comment that says it isn't.
Consistenly annotate format names for translation

The right macro to use in the fill function is N_(),
but some loaders were using _(). Correct this.
Use g_try_malloc_n where it makes sense

This lets us avoid some manual overflow checks.
Avoid some automake warnings
Avoid a compiler warning

Harmless NULL / FALSE confusion.
Avoid a discrepancy in file recognition

We are using a loader to implement some of the APIs that
are taking a filename, such as gdk_pixbuf_new_from_file_at_scale.
But the loader does not have the filename, so it can't use it
when determining the image type. This makes a difference for
types such as xbm, which have no good magic in the mime database.
Fix this by introducing a private API that lets us pass the
filename on to the loader.
Improve mime type detection

The mime database has no magic at all for xbm, and it
gets sniffed as text/plain. This is a regression from
when we were using our own magic, so be a little more
forgiving here - treat a mimetype of 'text/plain' like
uncertain results, and consult the filename. This lets
us at least recognize files with the extension .xbm
correctly again.

https://bugzilla.gnome.org/show_bug.cgi?id=573726
Add an xbm test

This tests that we correctly load a file with the .xbm extension
using both gdk_pixbuf_new_from_file and gdk_pixbuf_new_from_file_at_scale.
Update color table by value from pango #678996

For update have used values from https://git.gnome.org/browse/pango/log/tools/rgb.txt
that have already updated version of SVG/CSS pallete