When a virtual generated column is added to a table, it wasn't ensured that
data being calculated by GC's expression wouldn't get out of range of the
column. This might lead to inconsistent data being returned and unexpectedly
failed statements.

This patch adds two new options to ALTER TABLE:
1) WITH VALIDATION
2) WITHOUT VALIDATION (default)
e.g ALTER TABLE .. ADD COLUMN gc INT AS (...) VIRTUAL, WITH VALIDATION
These options are statement-level clauses, similarly to ALGORITHM or LOCK
clauses.
When the first option is specified, ALTER copies the table and if an
out-of-range error is thrown, or any other error occurs, the statement
fails.  Due to copy, such ALTER could take considerable amount of time on big
tables.
When these options are used without ADD/CHANGE/MODIFY COLUMN clause, the
ER_WRONG_USAGE error is thrown.

With the 2nd option, in-place ALTER is used (if possible) and data integrity
isn't checked and the statement finishes quickly. Drawback is that
errors/warnings might be reported during reading such column.

Options are used only during execution of the ALTER statement and isn't stored
anywhere in .FRM.

Now fill_alter_inplace_info() check whether validation is asked for and if
so, sets the newly added flag Alter_inplace_info::VALIDATE_VIRTUAL_COLUMN
to indicate that a virtual GC needs validation.
Storage engine's check_if_supported_inplace_alter() should check whether it
allows such operation to be in-place.

check_if_supported_inplace_alter() in both handler and ha_innodb classes
don't need any changes because they block in-place changes for all flags
other than explicitly listed in them.

(cherry picked from commit 29c6552ade0ff140f91b882b7a51940140589596)