replicated temporary tables must not be accessed by start_new_trans

The issue of actually allowed access to replicate temporary tables has existed since
start_new_trans "out-of-band" transaction implementation.
It hurts replication of temporary tables, implies the STATEMENT binlog-format,
and now is a real blocker to the Global Temporary Tables, as some of the changes
involved in the GTT work have brought this problem out as crashes, rather than
silently cause problems. See MDEV-37686 analysis for more details.

Though temporary tables are just one example of a broader issue, which is that
start_new_trans doesn't consider the slave's context when it resets a transaction's
state. I.e., start_new_trans resets the THD and transaction states, but the slave
context is retained. Temporary tables are broken because they are maintained by the
slave context, and thereby their state is retained after a new start_new_trans
begins.

The current idea for a comprehensive fix is to run these start_new_trans separate
transactions asynchronously in their own context, via a new dedicated thread or engage handle_manager.
This would ensure they have their own standalone context, and also increase concurrency. More details have
been discussed on PR #4462

Tentatively an approach pushed as bb-12.3-andrei is being tried first. It's idea is to add extra
checking of a possible start-new-trans context inside critical temporary table functions
(THD::lock_temporary_tables, THD::unlock_temporary_tables, and
THD::has_temporary_tables) that provide access to the replicated temporary table repo.
When it is found that the transaction is in a "start_new_trans-on-the-slave" context, it then
overrides the slave context to pretend the transaction is actually not run on the slave.