Fix Setup.hs if c_tmpdir already exists but is invalid

[tomsmeding]

Description
Changes Setup.hs to be more precise in the management of the cbits/tracy/{capture,profiler}/build/unix/obj symlinks.

Motivation and context
#536

Setup.hs arranges to have the Tracy build products, which would normally end up in cbits/tracy/{capture,profiler}/build/unix/obj, be put in the Haskell build directory. This is done by placing a symlink at the location that Tracy expects, pointing into Haskell build directory (typically dist-newstyle). At the end of the post-build hook this symlink is again removed.

However, this scheme goes wrong in the following convoluted situation:

• Build accelerate on a unix platform (in debug mode so that tracy is also built)
  • Interrupt the build halfway through compiling Tracy, so that the symlink is created but never removed
• Now switch GHC versions, so that the Haskell build directory changes (the GHC version is part of the path in dist-newstyle)
• Run cabal clean to remove the old build directory
• Rebuild.

The check if the symlink already exists returns False, because a symlink that points to a non-existent path appears to "not exist", and can only be seen by explicitly checking for a symlink. Thus, because "there is no symlink yet" (or so Setup.hs thinks), a new symlink is created, but that fails because there is already a symlink there. Thus the build crashes with createDirectoryLink:createSymbolicLink: already exists (File exists).

This PR changes the logic to explicitly check for symlinks, removing it if one already exists at the intended path. If a directory is found instead, we assume that this was intentional and we do not place a symlink, hence not redirecting the Tracy build products to the Haskell build directory. If a file is found instead, we error.

This can irrevocably remove a user-placed symlink at the obj path, but is difficult to distinguish from some old symlink that we put there, so we do not try.

How has this been tested?
Tested the five cases locally (nothing there, broken symlink there, valid symlink there, directory there, file there).

Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist
Go over all the following points, and put an x in all the boxes that apply. If you're unsure about any of these, don't hesitate to ask. We're here to help!

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[tmcdonell]

Thanks! :D