WL#6561: Deprecate and remove support for .sym files (custom symlink implementation)

Starting from Vista/Server 2008 a native symlinking mechanism is supported by
Windows (see mklink command). Since we don't plan to support Windows XP/Server
2003 starting from 5.6 this makes MySQL Server implementation of symbolic links
for Windows (based on custom .sym files) redundant. Therefore it is a good idea
first to deprecate and then remove completely remove code implementing this
custom symbolic links. Note that having this custom implementation around is a
bad idea not only from code complexity view point, but it also creates
performance problems in some scenarios.

Note that associated --symbolic-links parameter has a wider meaning as it also
controls whether DATA DIRECTORY/INDEX DIRECTORY clauses for MyISAM tables are
going to be ignored on Unixes. Thus it is probably a bad idea to changing value
of this parameter or deprecating it in the context of this task.

We can start by emitting deprecation warning first time when such table in such
a .sym-linked database is used.

References
==========
http://dev.mysql.com/doc/refman/5.6/en/symbolic-links.html#windows-symbolic-links
http://dev.mysql.com/doc/refman/5.6/en/server-options.html#option_mysqld_symbolic-links

Outline of suggested changes
============================

In 5.6:
-------
  * Emit a deprecation warning to server error log when a table in
    .sym-linked directory is used first time. Tentative wording:
    "Symbolic links based on .sym files are deprecated. Please use
    native Windows symbolic links instead (see MKLINK command)."

  * Add a test case that will test how symlinks work on Windows.
    The idea is to create a symlink from data directory to a 
    directory in scratch directory, thus creating symlinked
    database. Create a table in this database, run a few DML
    and SELECTs, drop this table.

In 5.7:
-------
  Remove all code implementing symdir support from the server.


Effect on backup/restore
========================

* mysqldump/mysql tool combination is unaware about .sym-linked
  directories but since it uses plain SQL for backup/restore,
  such directories are handled transparently by it. Contents
  of .sym-linked databases will be correctly dumped. During
  restore database will be recreated as normal non-symlinked
  directory. Implementation of this WL won't change behavior
  in this case.
* MEB is unaware of .sym-linked databases and doesn't care of
  them (i.e. doesn't support such databases). So removal of
  .sym-dir support won't change anything for it too.
* mysqlhotcopy script is unaware of .sym-linked databases too.
  So removal of .sym-dir support won't change anything for
  this tool either.

Additional notes
================
MKLINK command requires Administrator privileges (unless system
policies are changed). So it might be problematic to use it
from the standard test framework of MySQL.

Details
=======

In 5.6:
-------
  Extend unpack_dirname() function to return indication that
  during upacking directory name, we have opened .sym file
  and processed our custom symlink. To achieve this do similar
  change to symdirget() function.
  Change code in build_table_filename() to emit deprecation
  warning when unpack_dirname() indicates processing of .sym
  file first time after server start-up.

In 5.7:
-------
  - Remove USE_SYMDIR macro and all code withing #ifdef USE_SYMDIR .
  - Replace usage of my_disable_symlinks with my_enable_symlinks
    to facilitate next step.
  - Remove my_use_symdir global variable. In places where it is
    used to check if DATA/INDEX DIRECTORY clause should be 
    supported use my_enable_symlinks instead. Use
    my_enable_symlinks to store value of --symbolic-links
    start-up option.