WL#6057 Make semijoin work with single-table UPDATE/DELETE [patch 8/9, convert to multi-table if subquery]

Finally, making single-table UPDATE/DELETE capable of using semijoin
and subquery materialization, through conversion to multi-table.

should_switch_to_multi_table_if_subqueries() decides if the statement
is worth converting:
* has some IN or EXISTS subquery for which no hint prevents the use
of semijoin or subquery_materialization,
* and doesn't use LIMIT, ORDER BY, read-before-write removal.

The moment when we know for sure which of the single/multi code paths
we will use, is delayed a bit, from one place of Sql_cmd_update::prepare_inner()
to another place in the same function, so some operations are moved around.
For example, set_sj_candidates() is delayed.
The same is true for DELETE.
The assertion on JT_INDEX_SCAN, in safe_update_on_fly(), is something
which held before too.

* myisam_explain_non_select_all:
@@ -630,12 +638,14 @@
a plan was t1-with-IN-subquery, changed to t2(firstmatch)-t1;
thus as t1 is now second in plan, its updates are first buffered to
a tmp table, that explains the increase in Handler_% stats.
@@ -765,11 +783,11 @@
here, on the opposite, new plan is t1-t2(firstmatch),
so t1 remains first, and by using semijoin we have a good movement
of selection conditions: t1.a<3 moves from the subquery to the
first table, thus we read less of t1 and we get a decrease in Handler_% .

* subquery_mat: we see subquery materialization (not semijoin) now in use.

* hints-related tests: turned off semijoin to make sure the test
still tests what it wants.

* explain_for_connection_small_* : fixed the debug sync point, as now we don't
use a single-table DELETE for this statement, anymore.

* new tests upd_single_to_multi verify the WL's intended behaviour.

* subquery_table_to_derived: the new WL#13425, which can convert a
IN/EXISTS(subquery) to a derived table, gets automatically enabled
for single-table UPDATE/DELETE thanks to the present WL.

* Benchmarking results are recorded in the WL's page.

Change-Id: I26895fb3c3685e191b2244c7f8a7c012bd79bab9