The underlying problem here is that the "updatable" property as read
from the dictionary is not reliable: If the view in question is based
on another view, the updatable property is calculated when the view
is created. However, if an updatable underlying view is deleted and
replaced with a non-updatable one, the property is not updated.
Relying on this property eventually caused this assertion.

The fix is quite simple: calculate the is_updatable() property when
reading a view definition. This is much simpler than fixing it in
the dictionary implementation, since no dependency information is
available.

While debugging, it was also found that we have several other
deficiencies when data change statements are applied to views and
derived tables. A comprehensive test suite has been created to
check these statements, and some more fixes have been made to remedy
these problems.

Fix:

- The is_updatable() property is now generated solely without consulting
  dictionary information. It is set as true if any of the underlying
  tables of a view is updatable. A base table is both updatable and
  insertable.

- Add an is_insertable() interface for a table that can be checked in
  INSERT statements. This clarifies how tables are checked for INSERT.
  It is set true if all underlying tables of a view is insertable.

- check_view_single_update() is renamed to check_single_table_insert(),
  to clarify that function is used in INSERT.

- Initialization of materialized_derived_table_count in
  st_select_lex::resolve_derived() was deleted, since it made the
  function behave badly when called twice. The constructor init is
  sufficient.

- TABLE_LIST::leaf_tables_count() had to be changed slightly, since
  it may now be called on views that may contain materialized
  components.