Removing assumption of unsigned long pixel values for colours

[Alex Gramiak]

I've attached a WIP patch (for illustrative purposes) creating a new
union, emacs_color, that removes the single type limitation for the
internal representation of colours. This approach is intended to be used
with a new backend that I'm working on which uses a quadruple of
normalized double values for each colour rather than a single pixel
value. Using a union would avoid having to frequently convert between
the two representations.

I'd like to know whether this approach would be accepted (provided that
it's completed and submitted with a backend that uses it) before working
out the kinks and using it for the new backend.

Some issues that still have yet to be addressed in the patch:

* prepare_face_for_display takes in an XGCValues, which assumes unsigned
  long colour values. On non-X systems that create their own XGCValues,
  they can just be redefined, but on X that won't work. That means a new
  struct has to also be defined on X and then copied into an XGCValues
  in x_create_gc.

* The colors member of struct image was changed to use the new union,
  but XFreeColors expects an array of unsigned long pixels. It looks
  like the colors array is only used when COLOR_TABLE_SUPPORT is
  defined, so perhaps it could just used unsigned long unconditionally.


Question: In realize_gui_face, why is a defaulted underline colour set
to 0 when defaulted overline/strike-through colours are set to the
foreground colour? The comment above the underline case mentions that
it's the same as the foreground colour, so should it be explicitly set
there as well?

0001-Introduce-emacs_color-union.patch
Description: begone unsigned long