Bug#319  if while a non-transactional slave is replicating a transaction possible problem 

It is impossible to roll back a mixed engines transaction when one of the engine is
non-transaction. In replication that fact is crucial because the slave can not safely
re-apply a transction that was interrupted with STOP SLAVE.

Fixed with making STOP SLAVE not be effective immediately in the case the current
group of replication events has modified a non-transaction table. In order for slave to leave
either the group needs finishing or the user issues KILL QUERY|CONNECTION slave_thread_id.


mysql-test/suite/bugs/r/rpl_bug38205.result:
  bug#38205 non-deterministic part of tests results.
mysql-test/suite/bugs/t/rpl_bug38205.test:
  bug#38205 non-deterministic part of tests.
mysql-test/suite/rpl/r/rpl_start_stop_slave.result:
  bug#38205 deterministic part of tests results.
mysql-test/suite/rpl/t/rpl_start_stop_slave-slave.opt:
  increasing `innodb_lock_wait_timeout' to make the test pass on slow env w/o
  timeout expired issue.
mysql-test/suite/rpl/t/rpl_start_stop_slave.test:
  bug#38205 deterministic part of tests.
sql/log_event.cc:
  Augmenting row-based events applying with the notion of 
  thd->transaction.{all,stmt}.modified_non_trans_table.
  The pair is set and reset according to its specification
  for the mixed transaction processing.
  Particualry, once `modified_non_trans_table' is set in the row-events
  processing loop, it will remain till the commit of the transaction.
sql/slave.cc:
  Consulting `thd->transaction.all.modified_non_trans_table' to decide
  whether to terminate by the sql thread or to continue even though
  the sql thread might have been STOP-ed (rli->abort_slave).