WL#6145: Separate the dependence of DATA DIRECTORY from symbolic links

CREATE TABLE ... [DATA DIRECTORY] currently depends upon the availability of
symbolic links.  If symbolic links are not available, as on Windows, the phrase
DATA DIRECTORY is ignored.  But if a storage engine can track its own locations
for the data directory, that location should be provided.  Whether or not the
field is ignored should be decided in the storage engine.

There are 2 parameters that allow a table to be created using symbolic links in
the OS;

CREATE TABLE ... DATA DIRECTORY [=] 'absolute path to directory'] ...
CREATE TABLE ... INDEX DIRECTORY [=] 'absolute path to directory'] ...

The MySQL handler tests whether the OS supports Symbolic Links.  If not, it
sets the HA_CREATE_INFO::data_file_name and
HA_CREATE_INFO::index_file_name to NULL so that nothing is sent to the
storage engine.  That assumes that the only way a storage engine can use an
alternate data directory is through symbolic links.

InnoDB will add a tablespace system table to track alternate paths which
will not depend on symbolic links from the normal location to the alternate
path. See WL#5980.

In order to support that, this worklog moves the test for whether to use the
data & index file directories into the storage engines.  It does this by
deleting the test for symbolic link support in the MySQL server where it checks
whether to use these directories.  Those tests and the associated warnings that
DATA DIRECTORY and/or INDEX DIRECTORY are ignored, are moved into MyISAM and
Archive engines.  The Partition engine passes these directories on to the lower
storage engine, so the test for symbolic link support is removed.  InnoDB
currently ignores these two fields in HA_CREATE_INFO, so no work is needed in
this worklog for InnoDB.

There are 2 tests which are moved down to the storage engine;

1) HAVE_READLINK  is set in configure.cmake;
     CHECK_FUNCTION_EXISTS (readlink HAVE_READLINK)

2) my_use_symdir  is set with a startup parameter that has a conditional
   default value.  See mysqld.cc;
     {"symbolic-links", 's', "Enable symbolic link support.",
     &my_use_symdir, &my_use_symdir, 0, GET_BOOL, NO_ARG,
     /*
       The system call realpath() produces warnings under valgrind and
       purify. These are not suppressed: instead we disable symlinks
       option if compiled with valgrind support.
     */
     IF_PURIFY(0,1), 0, 0, 0, 0, 0},

InnoDB will ignore my_use_symdir since it is is related to the system call
to realpath() which is used for symbolic links.

In addition to the conditionals above, MySQL also uses some more related
conditionals in its code which do not need to be moved down to the storage engine;

1) HAVE_REALPATH  is set in configure.cmake;
      CHECK_FUNCTION_EXISTS (realpath HAVE_REALPATH)
   This is used in mysys\my_symlink.c to determine how to do the function
   my_realpath().  But there is a WIN32 version that uses GetFullPathName()
   so this condition does not need to be used in the storage engines.

2) HAVE_BROKEN_REALPATH is not set anywhere in mysql-trunk.
   According to a comment in cmake/os/FreeBSD.cmake, it "was used for
   really old versions of FreeBSD, roughly: before 5.1.9"

3) have_symlink  is a read-only system variable defined in sys_vars.cc;
      static Sys_var_have Sys_have_symlink(
         "have_symlink", "have_symlink",
         READ_ONLY GLOBAL_VAR(have_symlink), NO_CMD_LINE);
   This variable is disabled unless my_use_symlinks is true.  Then it is
   true unless HAVE_BROKEN_REALPATH is set.  This seems to be a display only
   variable used in a number of MTR test cases to determine if the
   DATA DIRECTORY will be ignored by the engines that use it.

4) SQL mode; NO_DIR_IN_CREATE
   See; http://dev.mysql.com/doc/refman/5.6/en/server-sql-mode.html
   SET @@global.sql_mode = NO_DIR_IN_CREATE;
   In code search for MODE_NO_DIR_IN_CREATE.  
   This setting causes the DATA DIRECTORY and INDEX DIRECTORY settings
   to be ignored  for all engines, including InnoDB for WL#5980