WL#6390: Use new DD API for handling non-partitioned tables

Use new DD for opening tables, and update DDL to support
new object(s). 

The goal here is to make MySQL server use new DD API
to store metadata instead of .FRM files. Following are some
requirements to achieve the same.

R1) Create new DD tables as part of mysql_install_db.

  We need to create new DD tables before any other
  table is created. So that metadata of rest all
  tables (this is created in mysql_install_db) is
  stored in new DD tables.

  The new DD tables uses foreign keys. InnoDB needs
  innodb_table_stats and innodb_index_stats in order
  to stored foreign key details. Hence we treat
  these 2 innodb tables as DD tables for now and create
  them along with new DD tables.

  As this WL is being handled before the new DD
  bootstrapping is implemented, we should still use
  .FRM for new DD tables until then. Once bootstrapping
  is implemented we can get rid of .FRM's for new DD also.
  For more details on Bootstrapping refer WL#6394.

R2) Prepare TABLE_SHARE reading metadata from DD tables
    and not from '.FRM'.

  This work is mostly about writing code that is equivalent
  to what is done in open_binary_frm().

R3) Write metadata from TABLE_SHARE to DD tables.

  This work is mostly about writing code that is equivalent
  to what is done in mysql_create_frm();

R4) Store and remove metadata for DATABASE's in DD tables,
    for CREATE/DROP DATABASE command.

R5) Store and retrieve metadata for TABLE's in DD tables.
    Metadata for TABLE includes column and index metadata.

R6) Support renaming table using new DD.

R7) Make ALTER table work using new DD tables.

  Mostly we don't need special handle to make ALTER table work.
  As it creates temporary table and then does rename,
  if DROP and RENAME table works fine using new DD tables,
  then ALTER table should work fine.

R8) Do not generate bin-logs for DML on DD tables.

  As DDL statement use statement-based binlog mode,
  the DDL statement log is generated at the end of DDL
  processing. So, DML's on DD tables should not generate
  additional bin-logs. 

R9) Enable recursive call to open_table() in MySQL server.

  Currently in MySQL server, we open all the required
  tables for execution of a statement at-once at the
  begining of execution. DD framework might need to open
  DD table in fetch metadata of user table.
  Eg:. to prepare TABLE_SHARE for user table that is
       being opened.

R10) DML's from DD framework should use dedicated separate
     transaction.

  This is a requirement from InnoDB, in order to support
  DDL recovery.

R11) Avoid creation of .FRM for user tables.

  There is lot of code that invokes OS file system calls
  to check existence of a table and database.
  We need to remove all this code in order to get rid
  of .FRM. 

R12) Store INDEX/DATA DIRECTORY options of CREATE TABLE
     among other table options.

  These options are supported for MyISAM/InnoDB only,
  and they are not stored in FRM files. However, in order to
  simplify the SE code, we've been asked to store them
  among other table options.


Note: Removal of FRM files is linked to this WorkLog.

NF1: No user visible changes.

Following are changes introduced by this WL.

Introduces a 'class Table_share_utils' encapsulating logic to
read and write TABLE_SHARE from DD tables.

Introduces new global functions or methods of Table_share_utils
which update DD tables using DD API's, which mostly replaces
existing code that accesses .FRM file. These functions can be
visualized as a glue code between server and DD API framework.


Schema operations:
------------------------------------

bool dd_create_database(...)
  Stores metadata of a schema into DD.

bool dd_remove_database(...)
  Removes metadata of a schema from DD.


Table operations:
------------------------------------

bool dd_remove_table(...)
  Removes metadata of a table from DD.

bool dd_rename_table(...)
  Renames a table in DD with new
table name.

bool dd_table_exists(...)
  To check if a table exists.

bool Table_share_utils::create_dd_user_table()
  Stores metadata of new user table into DD. Stores columns,
  index and index element metadata.

bool Table_share_utils::create_dd_system_table()
  Stores metadata of data dictionary table into DD.

bool Table_share_utils::prepare_share()
  Prepares TABLE_SHARE object from the metadata stored in DD.


view operations:
------------------------------------

bool dd_create_view(...)
  Stores metadata of a view into DD.

bool dd_create_system_view(...)
  Stores metadata of a system view into DD.

bool dd_read_view(...)
  Prepares a dd::View object from DD.

  We replace TABLE_SHARE::view_def of type File_parser* with
  TABLE_SHARE::view_object of type dd::View*.

bool dd_remove_view(...)
  Removes metadata of a view from DD.

bool dd_rename_view(...)
  Renames a view in DD with new view name.

bool dd_table_exists(...)
  To check if a view exists.


Rewrites of functions in datadict.*:
------------------------------------

bool dd_abstract_table_type(...)
  Given a schema and table name, retrieve the table or view,
  and assign an out parameter representing the table type,
  which is table, user view or system view. Return true on
  error, e.g. no table nor view found.

bool dd_table_legacy_db_type(...)
  Given a schema and table name, retrieve the table, and
  assign an out parameter representing the table legacy
  db type, which is encoded as one of the table options.
  Return true on error, e.g. no table found, or no legacy
  db type found among the options.

bool dd_table_storage_engine(...)
  Given a schema and table name, assert that we have at
  least a shared meta data lock on the table. Then, retrieve
  the table, and get the legacy db type. If non-dynamic, use
  it to get hold of the table's storage engine, and assign it
  to an out parameter. If the legacy db type is dynamic, use
  the engine field directly to get hold of the storage engine.
  Return true on error, e.g. no table found, or no storage
  engine found.

bool dd_check_storage_engine_flag(...)
  Retrieve the storage engine of the given table, and check
  if it supports the given flag. Assign the true or false
  to a bool out parameter reflecting whether the storage
  engine supports the flag. Return true on error, e.g. no table
  found, or no storage engine found.

bool dd_recreate_table(...)
  Assert that we have an exclusive meta data lock on the
  given table, and call ha_create_table(). This function is
  mostly unchanged since it does not directly use .FRM files.
  However, it builds an .FRM file path, which may be
  skipped when we abandon the .FRM files completely.


Tablespace operations:
------------------------------------
bool dd_create_tablespace(...)
  Stores tablespace metadata into DD.

bool dd_drop_tablespace(...)
  Drops tablespace metadata from DD.

bool dd_alter_tablespace(...)
  All/drop tablespace file metadata to/from DD.


Other improvements were done aiming to avoid utype/unireg_check
and pack_flag usage.