Ensure that creation and usage of temporary tables in replication is predictable

In some context, temporary tables on the master and slave can become inconsistent.
Example: If a temporary table is updated with the value of a nondeterministic function like UUID(), the change is never sent to the slave.
In some other context, while using MIXED mode, all changes will be logged in ROW mode while the user has any active temporary tables even if the temporary tables is not used in the query. This depends on in which format some previous independent commands where logged.

There are many other pitfalls with logging temporary table to the slave, which is why we are changing that, by default, temporary tables are only created on the slave if the master is using binlog_format=STATEMENT.

The new deterministic rules for logging of temporary tables are:

• STATEMENT binlog format is used. If it is binlogged, 1 is stored in TABLE_SHARE->table_creation_was_logged. The user can change this behavior by setting create_temporary_table_binlog_formats to MIXED,STATEMENT in which case the create is logged in statement format also in MIXED mode (as before).
• Changes to temporary tables are only binlogged if and only if the CREATE was logged. The logging happens under STATEMENT or MIXED. If binlog_format=ROW, temporary table changes are not binlogged. A temporary table that are changed under ROW are marked as 'not up to date in binlog' and no future row changes are logged. Any usage of this temporary table will force row logging of other tables in any future statements using the temporary table to be row logged.
• DROP TEMPORARY is binlogged only if the CREATE was binlogged.