Make backup locks compatible with cluster

UPDATE (KAlexey, 2014-06-28): it's been decided that a better way to retrieve Galera GTID would be to read TRX_SYS_WSREP_* fields from InnoDB data files. This way we don't need any additional locks to protect wsrep_last_commited during the backup stage, so this blueprint is unnecessary.

A Galera cluster node requires more data structures to be protected by
backup locks than a regular MySQL server. When backing a Galera cluster
node, backup tools also query the following status variables as a part
of the backup process:

wsrep_local_state_uuid
and
wsrep_last_committed

The former is assigned a value on server startup and never changes
during runtime. The latter is updated on each commit as the name
implies.

When backup locks are not available, those variables are queried on a
read-only server, i.e. under FTWRL, which also blocks commits, so
wsrep_last_committed is guaranteed to have a consistent value.

When backup locks are available, those variables are queried under LOCK
TABLES FOR BACKUP + LOCK BINLOG FOR BACKUP. None of those statements
currently prevents wsrep_last_committed from being updated.

The goal of this blueprint is to change the semantics of LOCK BINLOG FOR
BACKUP for Percona XtraDB Cluster: instead of blocking updates to binary
log coordinates (when binary log is enabled), LOCK BINLOG FOR BACKUP
should block all commits regardless of the binary log state, because
every commit will update wsrep_last_committed.