Building test scenarios using BuildManager.
Package restore and asserts
Moved scenario to subdirectory,
added copying to OutDir as part AfterBuild target
Tried to run build using DevEnv
Simplify MSBuild-based tests.
Merge pull request #1 from AArnott/tests

Simplify MSBuild-based tests.
Adds static global property to emulate building inside Visual Studio.
Remove DevEnv test support.
Retargeted from MSBuild v4.0 to MSBuild v12.

This reflects the actual MSBuild that NuProj in VS targets.
Reinstalled NuGet packages with the new target framework.
Removed DevEnv, test for "GetPackageIdentity" target.
Testing no longer blocks thread during NuGet package restore.
Merge Kovalikp's changes.
Merge pull request #2 from AArnott/tests

Add VS emulation support
Update project and license URLs
Allow overriding path to NuGet.exe

We currently make the assumption that the NuGet.exe is always in the
same folder as NuProj.targets. This is unfortunate as this makes it
harder to run NuProj directly from the source layout.
Ensure path to NuGet.exe is stable

We use NuGet.exe in two different contexts:

    (1) Restoring packages
    (2) In our implementation of NuProj

We currently use the same path to NuGet in both cases. This, however,
has the unfortunate side effect that opening the solution without
running a command line build first will not build.

The reason is that the NuGet.exe we use for package restore is only
retrieved when building from the command line -- the IDE will use a
different version of NuGet.exe.

In order to have a stable path we separate these two concerns. We'll
use a solution wide package reference to NuGet.CommandLine which is
the one we use for our implementation. This version of NuGet.exe is
guaranteed to be available -- regardless of whether a command line
build happened or not.

For package restore, we download the latest version of NuGet.exe from
http://nuget.org. However, to avoid confusion we don't place this one
anywhere in our source tree. Instead, we put it in the local app data
which also has the nice side effect that it will be shared between
different projects. The location is the same that ASP.NET vNext is
using.
Extract some common properties to build.props

The point of that file is to, huh, share properties. So it's a bit of
weird thing that virtually every project has to redefine $(OutDir).
Merge remote-tracking branch 'kovalikp/tests'
Add test for empty project.
Skip transitivity failing test.