(as long as replicate-*-table rules were defined, multi-table DELETE was never
replicated by the slave).


sql/sql_parse.cc:
  For a multi-table DELETE, there are two lists of tables:
  - 'tables' contains the tables in the FROM. They have 'updating==0'.
  - 'thd->lex.auxilliary_table_list.first' contains the tables between the DELETE and the FROM. They have 'updating==1'.
  So the bug was that the slave only tests 'tables' and as all its elements have updating==0,
  tables_ok() always returns 0.
  So for a multi DELETE the slave now tests the 2nd list too.
  I started with the other tip of the sausage: I thought of changing multi DELETE to use
  only one list (given that 'updating' can be used to separate it in two when needed)
  (with one list we wouldn't need to change the slave code), but finally hit the unicity
  check in add_table_to_list() which started to return ER_NONUNIQ_TABLE (logical).