Improve the performance of opam update/init on Windows

[kit-ty-kate]

WIP attempt at (temporary) fixing #5741 by throwing more silicon^Wdomains at the problem while #5648 is being worked on.

This currently requires:

• https://github.com/ocaml/ocaml-re/issues/287 to be fixed or alternatively we could just use mutexes for now
• https://github.com/ocaml/opam-file-format/pull/60 to be merged and released
• to remove or add a mutex around Stats.read_files
• find what makes the extra-files lookup warn with Mismatching extra-files at ...: missing from 'files' directory (1) on so many more unrelated packages
• more testing as i'm sure there are more races (data races should be taken care of as it passes with TSan enabled)

Current result:

• On Linux: opam update default goes from 6 seconds to 4 seconds
• On Windows: opam init --bare goes from 6 and a half minutes to 3 minutes exactly. Of that 3 minutes, 1 minute is unchanged and taken by the extraction of the tar.gz archive.

Partly inspired by NTFS really isn't that bad - Robert Collins (LCA 2020)

Related to #5591 Fixes https://github.com/ocaml/opam/issues/3171 Fixes https://github.com/ocaml/opam/issues/4455 Fixes https://github.com/ocaml/opam/issues/2442

[kit-ty-kate]

The PR is now fully working as far as i tested. However given the untested nature of this change, its presence in such a central piece of code and its reliance on big changes in underlying software (opam-file-format) I don't think it should be in 2.2 but i think it a good place to start to think about:

• what is actually needed for opam to move to OCaml 5 (especially on windows as it is currently untested)
• making part of the engine parallel
• changing in API to make it data-race free (the change in OpamConsole.log, uses of ocaml-re, removal of chdir, introduction of OpamLazy from https://github.com/ocaml/opam/pull/5877)

I'll split this PR into several smaller ones once 2.2.0 is out.