gfileutils: make g_file_set_contents() always fsync()

Previously, this function only called fsync() if @filename exists and is
non-empty. This behaviour was introduced when the function was first
written (6cff88ba) and shortly
afterwards (d20a188b) respectively, with
the latter justified as a performance optimisation.

This meant that g_file_set_contents() does not provide the guarantee
that developers assume it has, namely that after a call and a crash,
@filename will either contain its previous contents or its new
@contents. In practice, when it was previously non-existent or empty on
a bog-standard ext4 filesystem, it would often contain NUL bytes
matching the @length of @contents, requiring application developers to
explicitly handle this third case.

Given the documentation includes the word "atomic", we make this
function provide the guarantee that was previously implied but untrue,
and document it. If applications require higher performance at the cost
of correctness, they can open-code the old behaviour, or we can add a
new function to glib providing weaker guarantees.

https://bugzilla.gnome.org/show_bug.cgi?id=790638
11 jobs for 1302-file-set-contents-fsync in 27 minutes and 22 seconds (queued for 1 second)
latest
Status Job ID Name Coverage
  Build
passed #115742
cross-android_api21_arm64

00:01:35

passed #115743
cross-android_api28_arm64

00:01:34

passed #115744
cross-mingw64

00:02:16

passed #115741
fedora-autotools-x86_64

00:05:44

passed #115740
fedora-x86_64

00:05:25

canceled #115800
freebsd-11
freebsd-11-x86_64

passed #115745
win32
msys2-mingw32

00:10:46

passed #115746
win32
vs2017-x64

00:07:30

canceled #115788
freebsd-11
freebsd-11-x86_64

failed #115747
freebsd-11
freebsd-11-x86_64

 
  Coverage
skipped #115748
coverage