GitLab

As explained in previous commits, the _peek_ call is advantageous
because:
- It is less bug-prone as we don't have to handle freeing the string. In
  all the cases I changed, I even spotted at least 2 cases where we were
  leaking a string (in file-mng, `temp_file_name` is never freed; and we
  were also leaking in an error case of gfig).
- As a consequence of the previous point: simpler code with less lines.
- In local file cases, the _peek_ variant does not even need to allocate
  an additional string.
- In other case, if we query several times the path, it is allocated
  once and cached so it stays efficient.
- When possible, working on the GFile rather than on a path string may
  be more robust. For instance I changed one g_unlink() into a
  g_file_delete(). Actually most reading/writing should be done with the
  GIO API when possible, but I didn't want to change too much code
  logics on this commit.