This is a problem for EXPLAIN of an INSERT ... SELECT statement into
a multi-table view: The first table of the view was always displayed
as the table being inserted into, even if inserting into a different
table.

This bugfix has been slightly eased by some refactoring made in WL#5275.
EXPLAIN relied on LEX::leaf_tables_insert to be set correctly as
the "leaf" table to insert into. But the logic in
select_insert::prepare() was wrong: It would always assign the first
leaf table to this.

Notice that we now calculate insert_table_ref for an INSERT.
The bug fix is to rename LEX::leaf_tables_insert to
insert_table_leaf and copy the value from insert_table_ref.
(The renaming was made to synchronize the name of the table_list
 pointer with insert_table, which is the name of the user-supplied
 table (base table or view) being inserted into.)

We also realized that LEX::insert_table_leaf and the local variable
insert_table_ref was duplicates, so we have removed the local variable
wherever possible.

The calculation of st_select_lex::leaf_table_count and
st_select_lex::leaf_tables in mysql_insert_select_prepare() has also
been simplified.

There was also a problem with prepare_for_positional_update(), since
it was based on a table object that sometimes was not calculated yet.
The simple solution was to have two calls to
prepare_for_positional_update(), one for each place the insert table
is determined. It is unfortunate to have it in two places, but
the alternative is some bigger refactoring.