Renamed SolutionConfigurationName.csproj -> SolutionConfigurationNameVS10.csproj
Rename SolutionConfigurationName.sln -> SolutionConfigurationNameVS10.sln
Initial port to VS2013

Mere port from VS2010 with a new solution and project. It loads
correctly in VS2013 but it doesn't set variables for C++ projects
Moved debug launch program to main project file

Removed and ignored *.csproj.user files
Fix version typo: renamed SolutionConfigurationNameVS13 -> SolutionConfigurationNameVS12
First attempt to support ProjectCollection of C++ projects. Better support VS2013

The ProjectCollection was found as a internal property of VCProjectEngineShim. Try to set variables there cause an exception to be raised asking for a lock to be set first. Still unable to set the lock.

The project now should be 100% VS2013 only. Referenced correct Microsoft.Build.dll (v12.0)
Fixes wrong name reference to SolutionConfigurationNameVS13.csproj (correct is VS12)
Found the correct way to acquire the lock. Converted DisableMarkDirty -> SkipEvaluation

But not the attempt to set the property results in a deadlock. Converting
DisableMarkDirty -> SkipEvaluation seems more correct as the project may
need reeavalutation and SkipEvaluation seems just to block that temporarily
Fix compilation on VS2010
Fixed the deadlock when setting properties in the c++ ProjectCollection

Trying to asyncronously call CheckoutAsync as in the Nuget sample was almost for sure causing the deadlock. The call is not needed anyway
First attempt to load properties only on VC project loading.

This triggers another deadlock when:
1) attempting to change configuration;
2) loading a solution without a VC project an loading a VC project after.
Better ensures ProjectCollection is configured ad propert times. Still deadlocks

This commit is better in the sense that it tries to configure the ProjectCollection after full load of the solution.  Also it find the ProjectCollection 1) searching all the DTE loaded projects 2) basing on the project being loaded. It seems more correct but now it triggers deadlock even on solution load of a C++ project: it seems the deadlock is avoidable only if the project is not fully configured. awit code seems correct
Deadlocks fixed. Fix suggested by Jeff Clark

Trying to acquire the configuration name/platform from SolutionConfiguration2 when the lock was acquired was causing the deadlock.

Fix courtesely suggested by Jeff Clark, JClark@audyssey.com
Separate target output directories (VS10 and VS12)
State dependency on framework 4.5.1 also on the manifest

This is a VS2013 extension only
Updated the BUILD file with info for VS2013