fix: Improve handling of .gcno files

fix: Improve handling of .gcno files

When support for caching a compilation with coverage (producing a .gcno
file), the commit[1] made sure to avoid rewriting the input path to
relative with the motivation “also make sure to use the source file
path, since this is in the notes”. However, this seems to be unnecessary
since a relative input file path will be written as is to the .gcno, not
the absolute path. This is the case for at least GCC 4.7+ and Clang
3.6+. Fix this by potentially converting the input path to relative even
when generating coverage.

When investigating the above issue, I noticed that GCC 9+ includes the
current working directory (CWD) in the .gcno file. This means that we
have include the CWD in the hash when compiling with
-ftest-coverage/--coverage in order to replicate what the compiler would
produce. Since this makes it impossible get cache hits when compiling in
different directories, a new gcno_cwd sloppiness has been added for
opting out of hashing the CWD, with the tradeoff of potentially getting
an incorrect directory in the .gcno file.

[1]: 02d3f078bd2495b8db2264ae0b2c692b4c5ba1bd

Fixes #1032.