Bug#55798 Slave SQL retry on transaction inserts extra data into non-transaction table

The transaction modified non-transactional table will be binlogged with ROLLBACK if it
rolls back on master. It includes the case that all statements which modified
non-transactional table are binlogged outside(before) the transaction. 
Example:
  BEGIN
  INSERT INTO trans-table;
  INSERT INOT non-trans-table;
  ROLLBACK
it will be binlogged as:
  BEGIN
  INSERT INTO non-trans-table;
  COMMIT
  BEGIN
  INSERT INTO trans-table;
  ROLLBACK;
All statements in the second binlogged transaction modify only transactional tables and
are rolled back safely on master. So the second transaction should not be binlogged.

After 5.5, there are two caches for binary logs, a transactional cache 
and a statement cache. When executing a transaction, statements that 
modified only transactional tables are always put in transactional 
cache. Statements that modified non-transactional tables can be put in 
either transactional or non-transactional cache depending on different 
situations. In this patch, a flag is added to mark if there is any 
statement that modified non-transactional table in transactional cache. 
When rolling back a transaction on master, transactional cache should 
not be flushed to binary log, if there is no statement in it that 
modified a non-transactional table. Otherwise, it should be flushed into 
binary log followed by 'ROLLBACK' statement.

BUG#55798
When a temporary error(eg. Lock timeout) happens, Slave SQL thread will rollback the
transaction and retry it again. But it is possible that the transaction cannot be
rolled back safely. For example a non-transactional table has been modified by the
transaction. It will make master and slave diversely.

After this patch, SQL thread will not retry to execute a transaction which can not be rolled
back safely if temporary error is encountered.

It also did some refactoring on code related to THD_TRANS::modified_non_trans_table and
binlog_cache_data.