fileutil: Add lock around pathname caching

If two threads both call gs_file_get_path_cached() on the same GFile,
then it's possible that both threads see the pathname isn't cached,
and set the qdata.  The second one will end up freeing the cached
qdata from the first, causing it to read freed memory.

Fix this by just slapping a lock around the whole business.

This was observed in the real world in ostree where two threads were
calling gs_file_get_path_cached() on the shared repo->tmp_dir.

But really, what we want to do is two things:

1) Upstream this into gio
2) Stop using gs_file_get_path_cached() so much; instead, we
   should be using openat() and friends.  This will also
   avoid malloc, and help us earn our UNIX merit badge.
fileutil: Add initial directory-relative API

Modern UNIX come with a variety of filesystem API suffixed with "at",
like openat(), linkat(), etc.  The reason for their existence
is multiple.

First, if you're doing a lot of file operations in a directory, it's
simply more efficient to avoid having the kernel traverse potentially
long pathnames constantly.

Second, this avoids a problem where if a user does e.g.:
rm -rf somedir &
mv somedir othername
mkdir somedir
touch somedir/otherfile

We won't end up deleting otherfile, because all of our operations are
relative to the original "somedir".

The second rationale is unlikely to matter for OSTree since we'll
assume the user isn't going to move a repository around while we're
committing to it, but anyways, it's just better to use fd-relative
pathnames.