Fix bug related to mount points on Windows
Fix bug related to mount points on Windows

Summary:
# Problem

Buck ends up with a mixture of paths across different drives on Windows. This ends up breaking a core assumption in the Buck codebase, hence any tests will fail.

# Context

When Buck sets up the project root, it expands the current working directory (i.e., creates a path for `.`). It then calls `toRealPath()` and `normalize()`.

`toRealPath()` has peculiar behaviour on Windodws when it comes to mount points. Specifically, if Buck's cwd is a mount point (i.e., mounted using PowerShell via `drive.AddMountPoint()`), then `toRealPath()` will return the original drive which is the source of the mount point.

This then ends up returning a path on a different drive (e.g., `E:\`) than other paths derived throughout the codebase.

# Repro Steps

This can be reproduced on Windows machine as follows (executed as administrator):

  mkdir C:\some\path
  $drive = Get-WmiObject Win32_Volume -Filter "DriveLetter='E:'"
  $drive.AddMountPoint("C:\\some\\path")

Then, if you try launch a Java process from `C:\some\path` and try to call `toRealPath()` for `.`, it will resolve to `E:`.

# The Fix

If we pass `NOFOLLOW_LINKS`, the behaviour on Windows works correctly and expands to the cwd.

Reviewed By: mattjgalloway, irenewchen

fbshipit-source-id: d15f89f461ea9aa1e85f7f9983c6442f56e3c0c6

JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck,JoelMarcey/buck