Use file monitoring for pre-processor re-run checks (#11411)

[tdammers]

This replaces the previous preprocessor re-run logic ("if the
preprocessor output exists and is newer than the input, don't re-run the
preprocessor") with a file monitor, which takes both the input file and
the preprocessor itself into account, solving #11411.

To make this possible, each preprocessor is now tagged with a hash that
uniquely identifies the specific preprocessor version.

The process of finding the actual preprocessor (runPreProcessor) to
run has been split off from the actual running; this was necessary so
that we can get a unique hash of the preprocessor (including version)
without having to actually run it, while also avoiding duplicate work
and a potential mismatch between the hash and the actual preprocessor.
Hence, we now have configurePreProcessor, which returns a pair of the
former runPreProcessor action and the preprocessor hash.

Includes/supersedes #12065, which should be merged first.

---

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[sheaf]

Very clean and elegant fix on top of the preparatory refactor, fantastic.

It looks like you still need to add some changelog entries:

1. One very short one for the renaming involving lookupAndConfigureProgramVersion.
2. One for the actual fix and the changes to the PreProcessor datatype (I think it makes sense to bundle those together in a single changelog entry).

Like with the other MR, I suggest squashing commits and giving the final commit a nice commit message.