after rollback on master

When starting a transaction with a statement containing changes
to both transactional tables and non-transactional tables, the
statement is considered as non-transactional and is therefore
written directly to the binary log. This behaviour was present
in 5.0, and has propagated to 5.1.

If a trigger containing a change of a non-transactional table is
added to a transactional table, any changes to the transactional
table is "tainted" as non-transactional.

This patch solves the problem by removing the existing "hack" that
allows non-transactional statements appearing first in a transaction
to be written directly to the binary log. Instead, anything inside
a transaction is treaded as part of the transaction and not written
to the binary log until the transaction is committed.

mysql-test/suite/rpl/t/rpl_row_create_table.test:
  Removing positions from SHOW BINLOG EVENTS and using
  reset_master_and_slave to start on a fresh binary log each time.
mysql-test/suite/rpl/t/rpl_slave_skip.test:
  Adding explicit commit in AUTOCOMMIT=0 to make test work correctly.
mysql-test/suite/rpl/t/rpl_trigger.test:
  Adding test case for BUG#40116.
sql/log.cc:
  Changing commit logic in binlog_commit() to only commit when
  committing a real transaction or committing a punch transaction.