This font seems totally broken.

Fixes #128

Because FcDirCacheDeleteUUID does not reset the modification time on
the directory, and because FcDirCacheRead unconditionally creates the
UUID file each time it is run, any empty directory in the cache will
get its timestamp changed each time the cache for that directory is
read.

Instead, just leave the UUID file around as it is harmless.

The alternative would be to only create the UUID file after the cache
has been created and the directory has been discovered to be
non-empty, but that would delay the creation of the UUID file.
Signed-off-by: Keith Packard <keithp@keithp.com>

This avoids a situation triggers updating caches on a directory where .uuid file was removed.

Resolves: #107

Added two prefix modes:
  "relative" that makes the relative path be relative to current file
  "cwd" for relative to current working directory which implies current behavior.

Resolves: fontconfig/fontconfig#15

'~' in the filename was extracted to the home directory name in FcConfigFilename() though,
this behavior was broken by d1f48f11. this change fixes it back to the correct behavior.

fontconfig/fontconfig#110

Fixes fontconfig/fontconfig#109

Fixes fontconfig/fontconfig#96

GPerf seems not allowing the empty lines though, current recipes are supposed to drop them.
but seems not working on some env.
So taking the proper way to do that instead of incompatible things against platforms.

"value == FcTypeInteger" won't be true because it was converted to FcTypeDouble earlier

FcFontSetFont() accesses fs->fonts in that macro though, there was no error checks
if it is null or not.
As a result, there was a code path that it could be a null.
Even though this is unlikely to see in usual use, it might be intentionally created
in a cache.

So if fs->fonts is a null, we should consider a cache is invalid.