Remove channelmap or prove it works for big-endian

rsvg_filter_render() takes a channelmap parameter. The only caller passes "2103".

I think this parameter was added some time during the transition from libart to Cairo. We use CAIRO_FORMAT_ARGB32 everywhere, and in it each pixel is platform-endian 0xaarrggbb premultiplied.

So, we have:

/* On little endian */
guchar *pixel = <some pointer>;
guchar a = pixel[3];
guchar r = pixel[2];
guchar g = pixel[1];
guchar b = pixel[0];

/* On big endian */
guchar *pixel = <some pointer>;
guchar a = pixel[0];
guchar r = pixel[1];
guchar g = pixel[2];
guchar b = pixel[3];

I think the "2103" that is being passed is supposed to be able to extract r/g/b/a channels, in that order, from each 32-bit value in Cairo's encoding. But wouldn't that only work for little-endian machines? Does the channelmap value being used even work on big-endian machines?

Tasks for this bug:

• Check that filters can extract r/g/b/a correctly on big-endian machines.
• Make sure that in fact every function uses the channelmap; some may be poking at bits directly.
• Remove the channelmap as an argument into rsvg-filter's entry point, and handle it inside rsvg-filter completely.