Internal Improvement: Fix pango_color_copy() usage for Color.copy()

[leifgehrmann]

The copy() method for the Color object is currently broken. This was discovered in #47 by cAttte while refactoring all the classes. The blue component is not copied by pango_color_copy() and always defaults to 0.

A workaround for now is to manually copy the red, green, and blue components and instantiate a new object. Functionally this is identical to pango_color_copy(), so it's not a terrible compromise. But it does make the code in color.py a bit ugly.

The issue is not due to the Pango library itself. I've confirmed this by 1. confirming that a test for this exists, and 2. attempting to replicate the issue in C. See below for the program and commands I ran:

#include <pango/pango.h>

int main (int argc, gchar **argv) {
    printf("%d\n", pango_version());

    PangoColor color = { 1, 2, 3 };
    printf("%d, %d, %d\n", color.red, color.green, color.blue);

    PangoColor *copy = pango_color_copy(&color);
    printf("%d, %d, %d\n", copy->red, copy->green, copy->blue);
}

% gcc example.c -o example `pkg-config --cflags --libs pango`
% ./example 
15010
1, 2, 3
1, 2, 3

So the next layer up the chain that could be causing problems is the C-FFI.

So the next steps are to create a small proof of concept which implements PangoColor and some of the Pango functions and see if the issue can be replicated outside of pangocffi.