[Fontconfig] [patch]: serialize fontconfig data structures

[Patrick Lam]

My new patch is at,

http://plam.csail.mit.edu/~plam/tmp/fontconfig-serialize-diffs-050613.diff

This patch allows the fundamental fontconfig data structures to be
serialized.  I've converted everything from FcPattern down to be able
to use *Ptr objects, which can be either static or dynamic (using a
union which either contains a pointer or an index) and replaced
storage of pointers in the heap with the appropriate *Ptr object.  I
then changed all writes of pointers to the heap with a *CreateDynamic
call, which creates a dynamic Ptr object pointing to the same object
as before.  This way, the fundamental fontconfig semantics should be
unchanged; I did not have to change external signatures this way,
although I did change some internal signatures.  When given a *Ptr
object, just run *U to get back to a normal pointer; it gives the
right answer regardless of whether we're using static or dynamic storage.

I've also implemented a Fc*Serialize call.  Calling FcFontSetSerialize
converts the dynamic FcFontSets contained in the config object to
static FcFontSets and also converts its dependencies (e.g. everything
you'd need to write to disk) to static objects.  Note that you have
to call Fc*PrepareSerialize first; this call will count the number
of objects that actually needs to be allocated, so that we can avoid
realloc.  The Fc*Serialize calls then check the static pointers for
nullness, and allocate the buffers if necessary.  I've tested the
execution of fc-list and fc-match after Fc*Serialize and they appear
to work the same way.

One thing that I might want to look into is eliminating duplication e.g.
of FcLangSet and FcCharSet objects, for instance by canonicalizing them
in a hash table or something.  Such a change would save space (which is
now mmapped, but still.)

Another note is that the current version of fontconfig uses string
addresses to compare and sort strings.  My patch computes hash codes
instead of using string addresses, which are hard to use as a portable
hash code.

The remaining work is pretty simple; I just need to write fc-mmap.c using
this new API, satisfying all of keithp's constraints.

Please commit this patch.

pat