After transition to new data-dictionary MySQL 8.0 and subsequent move
of DDL checks for foreign keys to SQL-layer InnoDB's function
dict_create_foreign_constraints() became redundant.

It no longer stores anything in InnoDB data-dictionary (since it was
removed). It is not responsible for updating InnoDB's dictionary cache
either (instead we rely on later dd_table_load_fk() call to do this).
It only does some DDL checks for foreign keys which are duplicated by
SQL-layer or elsewhere in InnoDB code.

OTOH its code still does parsing of original ALTER or CREATE TABLE
statements, which causes a few corner-case bugs. It also creates
problems for further improvements in the foreign key area.

This patch removes dict_create_foreign_constraints() and associated
InnoDB code related to foreign key definitions parsing.

The following bugs are fixed as result:
- Bug#22364336 "ANOMALY IN ALTER TABLE ADD FOREIGN KEY" - spaces
  around dot in fully-qualified referenced table name were
  erroneously not allowed by InnoDB parser.
- Bug#28486106 "ALTER TABLE ADD FOREIGN KEY ... REMOVE PARTITIONING
  FAILS IF SELF-REFENCE" - adding a foreign key and removing
  partitioning from table was not allowed within same ALTER TABLE,
  even though theoretically this should have been possible.
  Again the problem was caused by InnoDB parser not detecting the
  fact that new table version was not partitioned.

Also this removes sub-optimal handling of case when parent table
resides in database named "aux" which was mentioned in bug#28703793
"CANNOT ADD FOREIGN KEY CONSTRAINT TO TABLES INSIDE A DATABASE
NAMED `AUX`" (which by itself is not repeatable in MySQL 8.0).

Finally, to minimize impact of dict_create_foreign_constraints()
check was added to SQL-layer to detect situation when user tries
to create several foreign keys on the table with the same name
at early stage of ALTER TABLE execution. This solves the issue
described in bug#16904122 "MULTIPLE FK WITH SAME NAME ALLOWED IN
ALTER".

Reviewed-by: Sivert Sorumgaard <sivert.sorumgaard@oracle.com>
Reviewed-by: Debarun Banerjee <debarun.banerjee@oracle.com>