A transaction could result in having an extra event after a query that
errored e.g because of a dup key. Such a query is rolled back in
innodb, as specified, but has not been in binlog.
It appeares that the binlog engine did not always register for a query
(statement) because the previous query had not reset at its statement
commit time. Because of that fact there was no roll-back to the
trx_data->before_stmt_pos position and a the pending event of the
errorred query could become flushed to the binlog file.

Fixed with deploying the reset of trx_data->before_stmt_pos at the end
of the query processing.


mysql-test/suite/binlog/r/binlog_innodb_row.result:
  a new test file to contain tests dealing with binlogging innodb with
  the row-based format.
mysql-test/suite/binlog/t/binlog_innodb_row.test:
  a new test file to contain tests dealing with binlogging innodb with
  the row-based format.
sql/log.cc:
  Flushing the pending row event at binlog_end_trans() is moved down to the commit
  branch.
  Resetting of trx_data->before_stmt_pos to the uninitialized value at the end of the
  statement is implemented in binlog_commit() and binlog_rollback().
  Asserting emptiness the transaction cache after reset() and the uninitilized value for the statement's savepoint binlog position.