This patch implements git support for NTFS symbolic link type reparse points.

* There is a specific privelege required to create symbolic links that is not
  generally associated with a standard user. This part is up to the user to worry
  about.

* NTFS reparse points differentiate between file and directory links.  This
  patch assumes file links are meant. (A separate patch will develop this
  further).

* This patch is not intended to implement symbolic links in the shell utilities.
  This means that as of when this was written, bash and gnu utilities do not
  handle them.

* Windows chdir behaves differently to *nix, and we need to unravel symbolic
  links for various operations to work as expected.

* For efficiency, as much as possible of the calls are done with wchar_t, before
  being converted to utf-8.  This is as much about avoiding dealing with windows
  default encoding as anything else.

* resolve_symlink needed to be replaced in lockfile.c since there are some
  issues with recognising absolute paths, as well as for efficiency with
  wchar_t.

This work was based on a combination of patches developed by the following
people:

original-by: Johannes Schindelin <johannes.schindelin@gmx.de>
original-by: Thorvald Natvig <slicer@users.sourceforge.net>

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

Required for msysgit which needs to know whether the target of a symbolic link
is a directory or file.

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

Windows NTFS symbolic links require specifying whether the target is a file or
directory at creation time.  This can partially be done by interrogating the
filesystem, however when creating symbolic links that are within a repository,
there can be no guarantee of the order of creation.

This patch enables the code to allow interrogation of the git cache to determine
whether a target will be a file or a directory.

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

The current msys does not have support for NTFS symlinks.  This includes in
'ln', 'test', 'rm'.

Here the commands are overridden to use windows cmd.exe instead of msys.
The implementation of test is quite expensive but works for the test.

'rm' needs to handle many scenarios. Symlinks are not supported at all by the
msys version.
* 'rm -rf' equivalent needs to first delete the files, and then the directories.
* Directory symbolic links need to use cmd.exe 'rmdir'
* file symbolic links need to use 'del'.
* A couple of places use 'rm -rf' on a mix of files and directories, so needs to
  be split up.

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

There are 2 reasons for this:
  * Under windows, ln() must determine whether the target is a directory or a
    file before creating the link.
  * msys doesn't handle dangling NTFS symlinks well (for example 'ls' will abort
    at that point, claiming the file doesn't exist).

So I have reordered commands to make sure our symlinks don't dangle from the
time of their creation.

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

needed to translate /c/ -> c: for comparison.

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

Required by msysgit while the msys core does not handle reading NTFS
Symbolic-Link Reparse Points.

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

Required for tests to work.

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>

t7800 failed under symlink enabled msysgit without symlink enabled perl/msys

Signed-off-by: Michael Geddes <michael@frog.wheelycreek.net>