STM: Catch exceptions in next_state for nicer UX

[jmid]

In STM, the next_state function describes how the pure model description changes across each cmd.
As documented, ideally this function should be pure.

Surprises lurk when this is not the case, such as ocaml-gospel/ortac#150 points 1. and 3. since
next_state is run both

• during generation in gen_cmds (sequential), gen_cmds_size (sequential/parallel), and gen_triple (parallel)
• during precondition asserts cmds_ok (sequential) and all_interleavings_ok (parallel)

With no generated input to print this thus yields unhelpful error messages such as:

ERROR: uncaught exception in generator for test STM test exception during next_state parallel after 1000 steps:
Exception: Dune__exe__Stm_next_state_exc.Random_next_state_failure

This PR catches exceptions in next_state in these former cases, leaving exception raising to the sequential and parallel QCheck properties, where input can be printed and shrunk.

As a result, an end-user instead receives a minimal call sequence giving rise to the exception in both sequential mode:

   Add 96


exception Dune__exe__Stm_next_state_exc.Random_next_state_failure

and in parallel mode:

                        |                
                     Add 9090            
                        |                
             .---------------------.
             |                     |                


exception Dune__exe__Stm_next_state_exc.Random_next_state_failure

The PR furthermore

• adds a regression test to the internal test suite
• updates the documentation for the changed functions

[jmid]

CI summary for c549513:

• Win bytecode 5.1 found an unexpected counterexample in Lin.Internal CList int test with Thread Lin.Internal Thread int CList test finds unexpected counterexample under bytecode #358 and crashed on threadomain [ocaml5-issue] Windows failures on threadomain #203
• Win bytecode 5.1 timeout during domain_spawntree - with Atomic [ocaml5-issue] Windows trunk bytecode domain_spawntree crash or deadlock #354
• 2 Win bytecode trunk timeouts (PR+push) during threadomain [ocaml5-issue] Windows failures on threadomain #203
• Cygwin trunk / part2 timeout during a 7446.4s Lin.Internal CList int64 test with Thread
• linux-ppc64le-5.2 segfaulted on sequential STM Array and Float.Array tests (revealing an outdated image) [ocaml5-issue] Crashes and hangs on ppc64 trunk/5.2 #380
• freebsd-amd64-5.1 failed to trigger Lin DSL Out_channel test with Domain Lin Out_channel test fails to trigger on FreeBSD #401

Out of 63 runs, 7 failed: 5 were genuine defects and 3 were test suite reliability related

[jmid]

CI summary for 17514a4:

• linux-ppc64le-5.2 segfaulted/aborted on sequential STM Array, Bytes, and Float.Array tests (revealing an outdated image) [ocaml5-issue] Crashes and hangs on ppc64 trunk/5.2 #380

Out of 63 runs, 1 failed (a genuine defect)

None of the failures from the two runs are related to the PR, so I'll merge.

[jmid]

CI summary for merge to main:

• Cygwin 5.1 / part1 timeout during Dynlink [ocaml5-issue] Deadlock in Dynlink test on Cygwin+MinGW+MSVC #307
• Linux trunk debug aborted during domain_joingraph [ocaml5-issue] Abort on domain_joingraph under debug runtime #402
• Windows 5.1 timeout during threadomain [ocaml5-issue] Windows failures on threadomain #203
• macOS trunk failed to trigger a counterexample in STM int ref test parallel asymmetric 'STM _ ref test parallel asymmetric' failure to trigger #364
• Cygwin trunk / part2 timed out, mainly due to a 5671.8s Lin.Internal CList int test with Thread run [ocaml5-issue] General Cygwin slowness #384
• linux-ppc64le-5.2 segfaulted/aborted on sequential STM Array, Bytes, and Float.Array tests (due to running an old image) [ocaml5-issue] Crashes and hangs on ppc64 trunk/5.2 #380

Out of 38 runs 6 failed with 4 genuine issues and 2 borderline ones (asym, Cygwin threads)