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
------
<>


RELATION TO XA
--------------
<>


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.