Memory data-race tests

[art-w]

This adds three negative tests for references, mutable record fields and arrays, that tends to trigger memory data-races (the tests are very similar, I'll let you choose which ones to keep!) It takes a lot of trials, about 50k on my computer on a good day, so perhaps the count = 100_000 is too low... and it's very hard for the shrinker to reproduce the observed data-race.

Many thanks to @OlivierNicole for recommending qcheck-lin as a way to confirm that my hardware is doing read/write reordering optimizations :)

[jmid]

Thanks a bunch for sharing these! :pray: :smiley: I'm happy to see that we can trigger such failures with sufficiently high counts!

ATM we are still moving things around and renaming - so I'll let this PR rest a bit until that has settled.

[art-w]

(... wow it successfully failed really fast on the CI https://github.com/jmid/multicoretests/actions/runs/3526003194/jobs/5913754957#step:10:1388 ! The test might be less fragile than I expected :D )

[jmid]

Note: We already have Array tests in https://github.com/jmid/multicoretests/blob/main/src/array/lin_tests_dsl.ml Because they test more Array functions they tend to find and report observed "sequential inconsistency" of these, rather than performing a focused data-race drilling of get and set. As such, there may be a good reason to run both though... :thinking:

For all three, I'm also wondering if playing with rep_count (how many times each instance is repeated) could help reduce the outer iteration count - and hence overall testing time :slightly_smiling_face: