Various build cleanups

[dra27]

This PR collects a whole load of related tweaks together which started from some checking done in #13093.

• As I noted in https://github.com/ocaml/ocaml/pull/13093#discussion_r1572325531, the build should avoid ever using absolute paths as we end up in the Dante's missing 10th circle (escaping rules). The first commit switches the winpthreads submodule to be referred using a relative path and adds comments in configure.ac which I should have put in #10135 originally.
• The next commit then simplifies the meta-programming between configure.ac and Makefile for these two submodules - i.e. configure.ac stops generating Makefile-fragments and simply emits strings, like it's supposed to.
• The next commit is a .gitignore entry we missed in #12954 (we also missed cleaning winpthreads-sources in distclean which is fixed a few commits later).
• I'm not sure how long it's been wrong, but the rule for cleaning yacc/wstr.obj (a Windows-specific object) didn't work because it relies on Makefile.build_config which isn't loaded in a clean target. That's also a bit of meta-programming / layer violation between configure/make which I'm not terribly fond of, but I don't have a better solution to hand at the moment.

• 12976 accidentally broke the ability to run make distclean from an unconfigured tree.

• Similarly to the yacc/wstr.obj issue, the winpthreads objects were never cleaned because the instructions relied on configuration which isn't loaded in a clean target.
• Morally, make clean ought to clean the flexdll objects, which is done in the next commit (it's only morally because make clean does clean the flexlink executable and for reasons of history flexdll's Makefile always compiles by specifying the .ml files on the command line, rather than the more traditional separate compilation and linking, so flexlink was always completely recompiled after a make clean).
• Finally, there's an unfortunate nit when working on the MSVC port that the winpthreads submodule ends up with untracked content because of the .obj files. I've fixed that by instead putting the winpthreads objects in runtime/winpthreads during the build.

cc @shindere, @shym, @MisterDA 🙂

[dra27]

Sorry for the lag. Dropping the clean statement was in my mind, but apparently I then didn't do it, so thanks for that one.

For flexdll, the $(ROOTDIR)/flexdll wasn't originally an accident, but it wasn't doing that for winpthreads ... and I decided I prefer your version anyway, so I've pulled that commit straight in, thank you!

[shindere]

Gabriel Scherer (2024/05/15 02:50 -0700):

Merged #13112 into trunk.

Thanks. In general I'd be happy to get a chance to review these things.