WL#2765: Interleaved transactions in binlog

MOTIVATION
----------
1. Long transactions using row-based replication is replicated
in-efficiently without this.
BACKGROUND
----------
Currently, transactions are grouped together in the binlog. This is expected to
cause performance problems with the advent of row-based replication, since the
size of a transaction can be much larger. Buffering a huge transaction before
writing it to the binlog will cause I/O churn and be bad for performance.
The solution is to allow transactions to be interleaved in the binlog. Several
proposals for interleaving are currently being discussed on dev-replication@.
DESIGN
------
<<Need to be further described>>
RELATION TO XA
--------------
<<needs to be investigated>>
POSITIONING
-----------
When transactions are interleaved in the log, we need to know
when the first active transaction started, as well as the position
we are currently executing. Thus it is not enough to just store
the Exec_relay_log_pos in relay_log.info.
SERIALIZATION
-------------
When the log is interleaved, at some point we need to
serialize it.
Alternatives:
1. Master
Before sending the log to the slave (in COM_BINLOG_DUMP),
the log is serialized.
2. IO
The IO thread serializes the log before writing the
relay log.
3. New serialization thread
The new thread reads the relay log and produces a serial
log to be read by the SQL thread.
4. SQL
The SQL thread starts multiple transactions in parallel
corresponding to the interleaved format of the binlog.