These fields are specified by our `P1689r3` paper, but are not actually
needed. The dependencies of the scanning results themselves can be
captured via normal depfile logic. Avoid saving this possibly-large
information in the scanning results. It is not needed by later steps.
Since commit f3eed2c49d (cmGlobalNinjaGenerator: use P1689 dependency
file format for Fortran, 2019-03-12, v3.20.0-rc1~454^2), Fortran stopped
working in a build tree whose path contains a symlink. The reason is
that the P1689r3 format's `work-directory` field gets populated with the
realpath (via `getcwd`) of the build tree instead of the logical path to
the build tree used for generating relative paths in `build.ninja`.
This causes the `Fortran.dd` file to get absolute (real)paths to `.o`
files, and Ninja does not match them with the relative `.o` file paths
in `build.ninja`.
Fix this by dropping use of the `work-directory` field. This restores
our prior approach of generating paths in the dyndep file using the same
forms of paths received from the buildsystem generator. The P1689r3
paper's format may need to be revised to account for this.
Fixes: #21683
The `work-directory` field has been moved into individual rules since
each one may correspond to a different compiler invocation and therefore
a different work directory.
Support for arbitrary binary paths has been removed for simplicity.
We now assume paths have a valid UTF-8 round-trip representation.
