Use the new object_type enumeration names within the codebase.

When testing whether symlinks are correctly checked out, examine the
`core.symlinks` configuration option to determine if symlinks are
supported in a repository, don't simply assume that Windows means that
symbolic links are not supported.

Further, when testing the expected default behavior of `core.symlinks`,
test the filesystem's support to determine if symlinks are supported.

Finally, ensure that `core.symlinks=true` fails on a system where
symlinks are actually not supported.  This aligns with the behavior of
Git for Windows.

To determine the canonical filename for a given path, we previously
looked at the directory entries on POSIX systems and used
GetFinalPathNameByHandle on Windows.  However, GetFinalPathNameByHandle
requires a HANDLE - the results of CreateFile - and you cannot
CreateFile on a symbolic link.

To support finding the canonical path of a symbolic link, simply use the
existing POSIX code to look at the directory entries.

On Mac OS, `realpath` is deficient in determining the actual filename
on-disk as it will simply provide the string you gave it if that file
exists, instead of returning the filename as it exists.  Instead we
must read the directory entries for the parent directory to get the
canonical filename.

Since the Linux platform has a case sensitive file system, the header name should be lower case for cross compiling purposes. (On Linux, the mingw header is called ```windows.h```).