deadlocks

Backport of revno: 2617.68.35

The problem was that if one connection is running a multi-statement 
transaction which involves a single partitioned table, and another 
connection attempts to alter the table to drop a non-existing partition,
(which of course will fail), the first connection still gets 
ER_LOCK_DEADLOCK and cannot proceed anymore.

This bug is no longer reproducable. This has also been tested with the
patch for Bug#46654 "False deadlock on concurrent DML/DDL with partitions, 
inconsistent behavior" which concerned a similar problem but where the 
ALTER TABLE is semantically correct.

Test case added in partition_sync.test.