WL#9540: New data-dictionary: refactor .FRM to New DD code

WL#6392 "Upgrade to Transactional Data Dictionary" introduced 
new code for converting information about tables from TABLE_SHARE
objects produced from .FRM files to to New-DD objects stored in
tables.

Unlike code in ALTER TABLE implementation which serves similar
purposes this code tries to by-pass opening of tables. Still
many pieces of this custom code resemble/based on code which
is already present in server.

The goal of this WL is to try to get rid of redundant code
introduced by WL#6392 by changing both upgrade and non-upgrade
code.

Particularly we aim to reduce redundancy related to custom code
which:

- handles virtual columns
- deals with partitioned tables
- produces description of indexes for dd::create_table() directly
  from KEY_INFO in TABLE_SHARE
- filling HA_CREATE_INFO
- ...

This can be achieved by changing code which is specific to upgrade
and extending existing code handling DDL.

User Documentation
==================

Code cleanup. No user documentation needed.

This is a refactoring worklog. It will  not add/remove/change any functionality.
Hence, there are no function requirements in the scope of the worklog.

There are no observable or interface changes in the scope of this worklog as it
is a refactoring work. It aims to reduce code duplication introduced by WL#6392.
The detailed description of the area which require refactoring is mentioned in
Low Level Design Specification.

Code from WL#6392 calls dd::create_dd_user_table() to create entry in
dictionary for the user tables. The arguments for dd::create_dd_user_table() is
created by reading .frm files created in mysql-5.7. There is some code
duplication in server in the execution of ALTER TABLE command and upgrade code
which can be avoided.

Code duplication Area and their handling is as follows:

HA_CREATE_INFO
--------------
   
HA_CREATE_INFO contains information about table options.
ALTER code creates it inside mysql_prepare_alter_table().
upgrade code creates it inside dd::fill_create_info_for_upgrade().

A new function is introduced : prepare_ha_create_info()
to be used by both ALTER and upgrade. This function will contain the common
assignments from both, ALTER and upgrade code flow.

List
-------------------

This list contains Create_field objects for all the columns present in the table.
All the column meta data is handled by this list when creating entry in data
dictionary. 

ALTER code creates it inside mysql_prepare_alter_table(). This information is
prepared for dictionary inside mysql_prepare_create_table() by calling
prepare_create_field().
upgrade code creates it by picking the necessary code from
mysql_prepare_alter_table(). This information is prepared for dictionary by
calling prepare_create_field(). This leads to code duplication.

A new function : prepare_fields_and_keys()
has been introduced to be used by both ALTER and upgrade code.
upgrade code now calls mysql_prepare_create_table() to prepare column and index
data for dictionary.


KEY
----
KEY contains all the index information to be used while creating dictionary
information.

ALTER code creates it inside mysql_prepare_alter_table(). This information is
prepared for dictionary inside mysql_prepare_create_table() by calling
prepare_key().
upgrade code uses the KEY directly from TABLE_SHARE object with necessary changes.  

A new function : prepare_fields_and_keys() { mentioned above too }
has been introduced to be used by both ALTER and upgrade code.
upgrade code now calls mysql_prepare_create_table() to prepare column and index
data for dictionary. It would be safer to construct Key_spec object and then
use prepare_key() to construct proper KEY consumable by dd::create_dd_user_table().

Other changes in Key handling :
- mysql-8.0 introduces invisible indexes.
- mysql-8.0 adds the flag to check if the index algorithm was explicitly 
  specified.
  These options are handled by parser when creating the table first time in 
  mysql-8.0. Upgrade code does special handling for above changes. All indexes
  read from .frm files are marked visible.

Opening of TABLE inside SE
--------------------------
Upgrade code opens InnoDB tables inside Storage engine to retrieve Foreign Key
information. TABLE open uses information from TABLE_SHARE. Hence, Key
information in TABLE_SHARE is fixed to enable opening of tables inside SE.
Opening of table is moved to a separate function : open_table_for_fk_info() in
the upgrade code.


Partition Information
----------------------
Partition information needs to be  parsed for extracting Item trees (for
partition expression and COLUMNS values).
This is done while opening the table in ALTER code path by
open_table_from_share(). Upgrade code duplicates the same code.
A new function unpack_partition_info() is introduced to be used by table opening
and upgrade code.