It was a forgotten rw_unlock(), due to the deadlock detector feature (so bug was only in 5.1-maria, not
6.0-maria).

mysql-test/suite/maria/r/maria3.result:
  result, all fine
mysql-test/suite/maria/t/maria3.test:
  Test of BUG#39697: two scenarios (transactional tables, and non-transactional table but dynamic row format so still taking the rwlock) where the hang happened.
  t2 added by this test was masked by a temporary table created earlier in the test, which we forgot to drop.
storage/maria/ha_maria.cc:
  use new macro
storage/maria/ma_blockrec.c:
  use new macro
storage/maria/ma_commit.c:
  use new macro
storage/maria/ma_init.c:
  putting address of dummy_transaction_object in --debug trace can be useful
storage/maria/ma_open.c:
  use new macro
storage/maria/ma_write.c:
  if local_lock_tree is true, we have acquired keyinfo->root_lock so need to release it before "goto err".
  A pair of assertions so that our usage of TrIDs is kept sensible.
storage/maria/maria_def.h:
  A macro so that changes of MARIA_HA::trn can be tracked with --debug. It helped to understand in what cases,
  in maria_write(), we could have !(info->dup_key_trid == info->trn->trid) && !share->now_transactional
  (answer: ALTER TABLE adding UNIQUE index on transactional table).