Handle the prefix attribute specially for the <include> directive

[hexclover]

Motivation

Currently, for all of the four directives that has the prefix attribute (include, dir, remap-dir, cachedir), when prefix is omitted or is default, calculate_path will just return the (possibly tilde-expanded) path as is, which is more or less the same as using cwd.

However, fontconfig actually handles the <include> directive in a special way: if the path supplied is relative, then the "config path" instead of the CWD is prepended to it; this path is determined when fontconfig is built, and on Linux this is usually /etc/fonts. This PR implements this behavior. Note the new behavior is by far not a 1:1 clone of the fontconfig library, but is closer.

The change is important because the "builtin" config files follows this convention. For example, /etc/fonts/fonts.conf usually includes conf.d, which gets resolved as /etc/fonts/conf.d; and there's usually /etc/fonts/conf.d/50-user.conf which includes fontconfig/conf.d and fontconfig/fonts.conf with prefix="xdg". That's the reason fontconfig finds and loads config files in ~/.config/fontconfig. So after this change, on a usual Linux setup (Arch, NixOS, etc.), loading only /etc/fonts/fonts.conf should be sufficient to recursively import everything in /etc/fonts/conf.d, ~/.config/fontconfig/conf.d/*, etc.

Changes

After this PR, calculate_path works like this:

• First, do tilde expansion on the path.
• If the resulting path is absolute, then don't add any prefix and return that path.
• Otherwise, prepend the prefix as usual.
  • For <include> the default prefix to prepend on Linux is /etc/fonts. On Windows, fontconfig uses GetModuleFileName to get the path. From its docs I guess that's the path to the executable, but I cannot test so I just don't prepend any prefix. (Still, I didn't run, I just tried to make sure it can build.)
  • For the other directives the default prefix to prepend is the ./. (The original "default" behavior here is to return the path as is, and they are equivalent for relative paths AFAIC. For absolute paths the new behavior is to return early, which AFAIC is more correct.)

P.S. The issue has already been reported to some consumers of this crate, e.g. RazrFalcon/fontdb#59. I think those went to the wrong place :-)