Add support for generating a Make compatible depfile

[dcbaker]

This allows fypp to communicate to build systems like Make and Ninja (including through build system generators like CMake and Meson) files that need to be implicitly included in the build graph. This is important for getting correct incremental rebuilds when such a file is changed.

[aradi]

This is a very nice addition, thanks! The only thing I am somewhat unsure about is the escaping, see my comments below.

[dcbaker]

Updated with the requested changes. I've also updated the test case, and added a couple of more cases, including one to explicitly test the escaping behavior.

[dcbaker]

I've rebased this across the recent code reorganization

[aradi]

OK, perfect (and sorry for the long delay times). I think everything is fine so far, and the PR should be merged.

I have one only API design question: What is the advantage of not writing the depfile already during the process_file() call, but requiring a separate write_dependencies() call. At latter, you have to pass the name of the depfile again, which had been already passed via the comman line option --depfile.

At the first glance, it seems more logical to me, to write the depfile during the process_file() call and not having the extra write_dependencies() method. Any views on this?

[ijatinydv]

Hey, I've been going through this PR pretty carefully because I'm working on a GSoC proposal to add incremental preprocessing to fpm, and this feature is exactly what I need for tracking #:include dependencies correctly. Wanted to try to help move things forward since this has been sitting for a while.
On @aradi API question :
I think folding it into process_file() is the right call. The way it works now, outfile gets passed twice and there's nothing stopping someone from calling write_dependencies() before process_file(), the API just silently gives wrong results. The integrated approach also matches how GCC's -MMD works, which is probably what most build system users already expect.

Something like this:

def process_file(self, infile, outfile=None):
    # ... existing processing ...
    if self._options.depfile and outfile and outfile != '-':
        self.write_dependencies(outfile, self._options.depfile)

write_dependencies() and get_dependencies() can stay public for anyone who needs finer control, but the common case becomes automatic.

One bug I noticed while reading:
Parser._included_files gets initialised in __init__ but never resets between calls. So if anyone reuses a Fypp instance across multiple files, the dependency list accumulates stale entries from previous runs:

tool = Fypp()
tool.process_file('a.fypp', 'a.f90')  # _included_files = ['x.inc']
tool.process_file('b.fypp', 'b.f90')  # _included_files = ['x.inc', 'y.inc']  ← x.inc is stale

CLI users won't hit this because run_fypp() creates a fresh instance every time, but fpm would be calling the API directly and reusing the instance, so this would actually affect my use case. Fix would be adding self._included_files = [] at the top of Parser.parsefile() and Parser.parse(), similar to how Builder.reset() already handles this for the builder.
I'm happy to open a small follow-up PR with both of these if that makes it easier to get this merged. Thanks for the work on this, it's a genuinely useful feature.

[aradi]

Dear @ijatinydv , thanks for reviving this issue. Definitely interested in the feature, so feel free to make PRs, I agree on both points. (I'll be away from keyboard for somewhat more than a week, though, so my response times might become somewhat longish again.)