Deadlock between starting a slave and reading system variables

Starting the SQL thread might deadlock with reading the values of the
replication filtering options.

The deadlock is due to a lock order violation when the variables are
read or set. For example, reading replicate_ignore_table first
acquires LOCK_global_system_variables in sys_var::value_ptr and later
acquires LOCK_active_mi in Sys_var_rpl_filter::global_value_ptr. This
violates the order established when starting a SQL thread, where
LOCK_active_mi is acquired before start_slave, and ends up creating a
thread (handle_slave_sql) that allocates a THD handle whose
constructor acquires LOCK_global_system_variables in THD::init.

The solution is to unlock LOCK_global_system_variables before the
replication filtering options are set or read. This way the lock
order is preserved and the data being read/set is still protected
given that it acquires LOCK_active_mi.
Raise t6 extra version to 1.
Merge branch 'MYSQL-74' into t6.1-dev
Merge commit 'mysql-5.5.23.t6.1' into t7-dev

Conflicts:
	VERSION
Print ISO date and PID with all error log messages.

The problem is that the currently available fields that compromise
the header of error log messages, which are the date and time, plus
the severity of the message, do not provide the enough information to
identify discontinuity in reporting or which process generated a
message.

To make such identification possible, this change includes the
process ID in the header so that any changes in its value will
identify the source (process) of the message and also indicate any
discontinuity in reporting.

Additionally, the format of the date and time is changed to the ISO
format (YYYY-MM-DD hh:mm:ss). The previous format was non-standard
and difficult to read.
Bug#65715: Wrong connection ID (thread ID) in the general and slow query logs

The problem is that connection IDs (thread IDs) above 2^32 are not
properly written to the general query log. The method used to write
commands to the log (e.g. MYSQL_QUERY_LOG::write) uses a 32-bits wide
integer to store the connection ID value, which is actually a 64-bits
wide integer value, thus causing the higher bits of the value to be
discarded.

The solution is to simply use the correct type for storing thread IDs,
which is my_thread_id (unsigned long).
Provide the resulting error code for queries printed to the slow log.

The slow query log did not provide enough information to determine if
logged SQL statements completed successfully or whether they failed for
some reason (e.g. killed). To make this easier, the resulting error
number of a slow SQL statement is now printed to the slow query log
under the "Error_code:" field.
Expose current RBR execution state in the SQL Thread state

The execution of row-based events in a replication slave is not
reflected in the SQL Thread state, making it rather difficult to
identify long-running events. For example, the execution of a large
row-by-row delete event is not immediately identifiable as the
replication SQL thread state for most of its duration stays as
"Reading event from the relay log".

This change adds two new states to the replication slave SQL thread
that are used to highlight the event that the SQL thread is executing
and, for row-based events, to indicate how many rows have been
applied. These will generally look like:

        Executing Delete_rows event at position 100
        Handling record 50 of 100 for a Delete_rows event

Additionally, the outermost state of a thread state is now saved and
restored when inner states are set, so that the overall information
of what the thread is doing is not lost.