MDEV-10804 main.stat_tables_par fails sporadically in buildbot

This was because of two issues:
- thr_multi_lock_after_thr_lock needed to be hit 3 times before go2 could
  be signaled, because 2 of these happened before statistics_update_start
  was reached.
- The original code didn't take into accunt that thr_locks can be executed in
  any random order, which caused sporadic failures when waiting for 1 lock
  of 3, as if the locks where in different order, there would be a dead-lock.
  Fixed by introducing thr_multi_lock_before_thr_lock which is deterministic.
- Some of the test failures where not noticed as the DEBUG_SYNC timeout
  would cause the test to pass (after 300 seconds).

mysql-test/r/stat_tables_par_innodb.result

@@ -266,7 +266,7 @@ connect  con1, localhost, root,,;
 connect  con2, localhost, root,,;
 connection con1;
 set debug_sync='statistics_update_start SIGNAL parker WAIT_FOR go1 EXECUTE 1';
-set debug_sync='thr_multi_lock_after_thr_lock SIGNAL go2 EXECUTE 2';
+set debug_sync='thr_multi_lock_before_thr_lock SIGNAL go2 EXECUTE 3';
 use dbt3_s001;
 analyze table lineitem persistent for all;
 connection con2;