In some cases a DROP TRIGGER statement could hit a DBUG_ASSERT in
debug builds if the trigger was defined on a table that contained a
generated column. The same DBUG_ASSERT could under some circumstances
be hit when calling a stored function that referenced a table that
contained a generated column.

The DBUG_ASSERT was hit during re-resolving (aka "refixing") of the
generated column expression. The first time a statement opens a table
that contains a generated column, all the generated columns in that
table will be re-resolved to ensure that they are in a pristine state.
The DBUG_ASSERT (in TABLE_LIST::map()) fails because the TABLE_LIST
object associated with the Item_field that is being re-resolved, is in
an inconsistent state where m_map is not in sync with m_tableno.

The TABLE_LIST objects in question are allocated in
sp_add_to_query_tables() in the DROP TRIGGER case and in
sp_head::add_used_tables_to_table_list() in the stored function case.
Common for these two functions is that they initialize the TABLE_LIST
objects by manually setting the various members, instead of calling
TABLE_LIST::init_one_table(), which is the common way of initializing
such objects. This manual initialization forgets to set the m_map and
m_tableno members to values that are consistent with each other.

The fix makes the functions use init_one_table() to initialize the
TABLE_LIST objects. init_one_table() also needed a little reorganizing
to allow more flexible initialization of the associated lock request.