Improve the file share story

There are many reasons for wanting to have your source code on a file share instead of on a local drive. I'm for instance using Windows inside of [Parallels](https://www.parallels.com/) while hosting the source code on my Mac so I get tight integration with the OS X terminal for Git command line and all that jazz.

Having the source code Visual Studio is loading on a file share are problematic for quite a few reasons, some of which are way out of scope for the Roslyn Project System, but I thought I'd mention them anyway:
1. I need to run Visual Studio with elevated permissions (as the Administrator) to have it configure IIS and such. Since I have a habit of double-clicking on `.sln` files in Windows Explorer, I needed to get Visual Studio 2015 to do this by default, by:
1. [Configuring `devenv.exe` to always run as an administrator](https://stackoverflow.com/questions/12257110/can-you-force-visual-studio-to-always-run-as-an-administrator-in-windows-8). This made Visual Studio launch with a `devenv.exe` solution when, which forced me to:
2. Also [configure `VSLauncher.exe` to always run as an administrator](http://rick.bloggingabout.net/2015/04/16/running-visual-studio-as-an-administrator-causes-save-changes-to-devenv-sln-when-double-clicking-solutions/). Light-years from intuitive, but it works.
2. Since Visual Studio needs to be run with elevated permissions, the drives that are automatically mapped up by Parallels for my user, need to be manually mapped up by a login script with `net use` since even thought I do `/persistent:yes`, they are gone on every login.
3. To have Visual Studio "trust" the network share, I've had to [disable the "Warn user when the project location is not trusted" checkbox in Visual Studio](https://msdn.microsoft.com/en-us/library/bs2bkwxc.aspx), [use `caspol` to grant permissions to the network share](https://msdn.microsoft.com/en-us/library/zdc263t0%28VS.80%29.aspx?f=255&MSPPError=-2147217396) as well as [grant permissions to the local intranet code group](https://stackoverflow.com/questions/2603144/the-project-location-is-not-trusted-error-in-visual-studio). I think I had to do `caspol` for different versions of .NET as well, but I don't remember the exact details. Again, light-years from intuitive, but it seems to work.
4. When Visual Studio has loaded a solution on a network share, it is much less attentive to file changes that have happened outside of Visual Studio, such as a `git checkout` command executed in OS X.

As I wrote, some of these problems can't be attributed to the project system and are thus out of scope for this repository, but I just wanted to mention the whole story so you (as Microsoft) can understand just how much friction is involved here.

The probably worst thing is that I have to search for how to do each and every of the above steps each time I install Windows and/or Visual Studio, because it seems to be a variation on all of the above for each version of both Visual Studio and Windows. The steps are in any case so complicated to perform that I don't have enough cognitive capacity to remember between each time I reinstall, which I thankfully don't do very often (which of course affects my memory as well).

This relates to #169 in some ways, but I think the network share story requires its own user story, so here we are.

If you can improve on this in any way, you would add years to my expected lifespan for sure. If you can't, then at least now I have the required steps written down, so I can hopefully come back to this issue in the future to remind myself just how I did all of this. Thanks!