Hardcoded paths to cl.exe and ml64.exe in with-dkml cache

[jonahbeckford]

During an upgrade of Visual Studio the build number may change. The build number is the third and fourth set of digits in 16.6.30309.148 -> 16.6.30320.27; confer https://learn.microsoft.com/en-us/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2019&preserve-view=true.

The build number has some (complicated) relationship with the directory that cl.exe and ml64.exe lives in. Example:

C:\DiskuvOCaml\BuildTools\VC\Tools\MSVC\14.29.30133\bin\Hostx86\x86\ml.exe

The directory 14.29.30133 above can change during an upgrade.

• Invalidate the with-dkml cache when cl.exe disappears (maybe; this may already be done), and/or
• Invalidate all of the opam switches (probably impossible) or at least error to the user that their switches have to be rebuilt.

Don't assume that code that worked in one version can be linked to code for another version. I've seen GitHub Actions do a rolling upgrade, and the cached opam switch caused compilation errors during the upgrade. It might have been caches from new machines caused problems on old machines ... which isn't too unusual and can be explained away that new machines introduced new symbols that were unavailable on old machines. But the behavior could vary from upgrade to upgrade.