not to be the bringer of bad news re: Windows, yet here we are

doc/todo/windows__58___prepare_for_Win32_not_export_c__95___entities.mdwn

@@ -0,0 +1,55 @@
+I was going to report a bug with the transition to lts-19.13 in stack.yaml as I couldn't
+get for instance commit [[!commit d2bc2683173ca1ade437aa294b26fd5e54353a55]] "lts-19.13 (ghc 9.0.2)"
+that introduced it to compile on windows (with stack). But then I procrastinated too long and commit
+[[!commit d01530ac21aead6607085b5cc90b62a52acd03a9]] came along which reverted the transition and
+went back to lts-18.13 due to Joey having trouble getting ghc 9.0.2 to install. That was kind of fortunate
+to me because I didn't want to be the bringer of bad news regarding Windows in a bug report setting.
+
+The problem with compiling with LTS 19 on Windows is the following:
+
+[[!format sh """
+[...]
+[109 of 670] Compiling Utility.LockFile.Windows
+
+Utility\LockFile\Windows.hs:64:17: error:
+    * Variable not in scope:
+        c_CreateFile
+          :: LPTSTR
+             -> AccessMode
+             -> ShareMode
+             -> GHC.Ptr.Ptr a0
+             -> CreateMode
+             -> FileAttributeOrFlag
+             -> GHC.Ptr.Ptr a1
+             -> IO HANDLE
+    * Perhaps you meant `createFile' (imported from System.Win32.File)
+   |
+64 |                 c_CreateFile c_f gENERIC_READ sharemode security_attributes
+
+   |                 ^^^^^^^^^^^^
+Completed 229 action(s).
+
+--  While building package git-annex-10.20220624 (scroll up to its section to see the error) using:
+      C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-220630-d2bc26831\.stack-work\dist\d53b6a14\setup\setup --builddir=.stack-work\dist\d53b6a14 build exe:git-annex --ghc-options " -fdiagnostics-color=always"
+    Process exited with code: ExitFailure 1
+"""]]
+
+I digged into this and it turned out that as of Win32-2.12.0.0 it does not include those bindings
+anymore that begin with `c_` in its exports and considers them as internal details. Unfortunately in
+System.Win32.File the alternative, `createFile`, is a "cooked" API in the sense that if there are
+intermittent errors opening the file there is some Haskell code that busy-waits on behalf of the user.
+But according to Joey that is undesirable for a lockfile implementation (.\Utility\LockFile\Windows.hs:53):
+
+```
+ - Note that createFile busy-waits to try to avoid failing when some other
+ - process briefly has a file open. But that would make checking locks
+ - much more expensive, so is not done here. Thus, the use of c_CreateFile.
+ 
+```
+
+So what to do when the authors of module Win32 pull the rug from under you? Should we perhaps weave
+our own tiny c_CreateFile API with FFI, or, could we do without it and use one of the implementations
+using Windows LockFileEx, for instance the one by my compatriot: <https://hackage.haskell.org/package/lukko>
+
+[[!meta title="windows: prepare for System.Win32.File not exporting c_ entities"]]
+[[!meta author=jkniiv]