by introducing new Item::precedence() method and using it
to decide whether parentheses are required

* do setup/cleanup for charset and arena only once per table
  not for every vcol
* don't copy every vcol expression into table's memroot for parsing,
  do it in a temporary String buffer that is freed at the end
* add asserts

now, when expr_str is gone, expr_item can be unambiguously
renamed to expr.

otherwise we'd need to store sql_mode *per vcol*
(consider CREATE INDEX...) and how SHOW CREATE TABLE would
support that?

Additionally, get rid of vcol::expr_str, just to make sure
the string is always generated and never leaked in the
original form.

it must, because purge opens a table that might be being altered right now

  * remove old 5.2+ InnoDB support for virtual columns
  * enable corresponding parts of the innodb-5.7 sources
  * copy corresponding test cases from 5.7
  * copy detailed Alter_inplace_info::HA_ALTER_FLAGS flags from 5.7
     - and more detailed detection of changes in fill_alter_inplace_info()
  * more "innodb compatibility hooks" in sql_class.cc to
     - create/destroy/reset a THD (used by background purge threads)
     - find a prelocked table by name
     - open a table (from a background purge thread)

  * different from 5.7:
    - new service thread "thd_destructor_proxy" to make sure all THDs are
      destroyed at the correct point in time during the server shutdown
    - proper opening/closing of tables for vcol evaluations in
       + FK checks (use already opened prelocked tables)
       + purge threads (open the table, MDLock it, add it to tdc, close
         when not needed)
    - cache open tables in vc_templ
    - avoid unnecessary allocations, reuse table->record[0] and table->s->default_values
    - not needed in 5.7, because it overcalculates:
      + tell the server to calculate vcols for an on-going inline ADD INDEX
      + calculate vcols for correct error messages

  * update other engines (mroonga/tokudb) accordingly

remove 'table' argument, remnant of 5.6, does not exist in 5.7

* remnant of 5.6, does not exist in 5.7. bad merge?
* also remove dict_table_get_col_name_for_mysql(), it was only
  used when index_field_t::col_name was not NULL

* fix "unused pending_checkpoint_mutex_key" compiler warning
* clarify/simplify get_field_offset()
* typos, comments
* unused (forgotten) declaration of create_options_are_invalid()
* fix my_error(ER_WRONG_KEY_COLUMN) calls
* crash in row_upd_sec_index_entry()
* double if (ret != 0)
* don't duplucate PSI_INSTRUMENT_ME lines
* useless break; after return();
* remove unused xtradb-only "cursor_read_view" stuff
* code formatting
* simplify dropped column detection
* redundant assignment

and THD::inc_thread_count

Use TABLE::init_one_table(), don't duplicate it.
Put additional initializations into TABLE::init_one_table_for_prelocking()

instead of returning strings for CASCADE/RESTRICT
from every storage engine, use enum values

* wrong results for 5.7 and 10.1- vcols, and for indexed vcols
* only helps in rare cases and only minimally

partitioning was setting subj as a partitioning-specific
hack (GET_FIXED_FIELDS_FLAG field flag to detect partitioning fields)
inside init_lex_with_single_table(). But vcols also use
init_lex_with_single_table(), they run fix_fields()
in open_table_from_share() before partitioning and this messes up
partitioning GET_FIXED_FIELDS_FLAG logic.

When updating a table with virtual BLOB columns, the following might happen:
- an old record is read from the table, it has no virtual blob values
- update_virtual_fields() is run, vcol blob gets its value into the
  record. But only a pointer to the value is in the table->record[0],
  the value is in Field_blob::value String (but it doesn't have to be!
  it can be in the record, if the column is just a copy of another
  columns: ... b VARCHAR, c BLOB AS (b) ...)
- store_record(table,record[1]), old record now is in record[1]
- fill_record() prepares new values in record[0], vcol blob is updated,
  new value replaces the old one in the Field_blob::value
- now both record[1] and record[0] have a pointer that points to the
  *new* vcol blob value. Or record[1] has a pointer to nowhere if
  Field_blob::value had to realloc.

To resolve this we unlink vcol blobs from the pointer to the
data (in the record[1]). Because the value is not *always* in
the Field_blob::value String, we need to remember what blobs
were unlinked. The orphan memory must be freed manually.

To complicate the matter, ha_update_row() is also used in
multi-update, in REPLACE, in INSERT ... ON DUPLICATE KEY UPDATE,
also on REPLACE ... SELECT, REPLACE DELAYED, and LOAD DATA REPLACE, etc

multi-update was setting up read_set/vcol_set in
multi_update::initialize_tables() that is invoked after
the optimizer (JOIN::optimize_inner()). But some rows - if they're from
const tables - will be read already in the optimizer, and these rows
will not have all necessary column/vcol values.

* multi_update::initialize_tables() uses results from the optimizer
  and cannot be moved to be called earlier.
* multi_update::prepare() is called before the optimizer, but
  it cannot set up read_set/vcol_set, because the optimizer
  might reset them (see SELECT_LEX::update_used_tables()).

As a fix I've added a new method, select_result::prepare_to_read_rows(),
it's called from inside the optimizer just before make_join_statistics().

This fixes a bug where handler::read_range_first (for example)
needed to compare vcol values that were not calculated yet.

As a bonus it fixes few cases where vcols were calculated twice

sql_insert.cc calls handler->ha_update_row() for
REPLACE and INSERT... ON DUPLICATE KEY UPDATE

cannot use TABLE:merge_keys for that, because Field::part_of_key
was designed to mark fields for KEY_READ, so a field is not a
"part of key", if only prefix of the field is.

* don't issue an error for ER_KEY_BASED_ON_GENERATED_VIRTUAL_COLUMN
* support keyread on vcols
* callback into the server to compute vcol values from mi_check/mi_repair
* DMLs just work. Automatically.

update tests and results, fix bugs

will be used later by storage engines (e.g. in MyISAM repair or in
InnoDB purge)

because it's only doing to show the table structure, not look
at the data.

always set them according to the repair method used

and declare few other Field getters to be 'const'

Make update_virtual_fields() a method of TABLE, to be consistent
with TABLE::update_default_fields().

TABLE::mark_virtual_col() was polluting table->vcol_set
and that confused the following mark_virtual_col()