SDK-based project with new target platforms

[3F]

Closes #11

Update 1

Target platforms

So, what we decided for today:

I already described process of using with new msbuild packages (contains logic with new Installation API that fixes all active third-software problems) via getnutool + vssbe scrips in issue on nuget project.

However, I still have thoughts about dynamically fixing this dependency. I mean some automation, or rather delegation of responsibilities to ~a configurable loader, accessible to end-users. Here mentioned: #5

Therefore, today's solving the problem of the new API (and more) we will still decide in the same manner like in our wiki: https://github.com/3F/MvsSln/wiki/Examples-override-MS-Project

And finally we'll make today's support for netcore very simple using their available platforms.

(Obsolete)

This adds at least netstandard2.0 and net40.

• https://github.com/dotnet/standard/blob/master/docs/versions.md#net-standard-versions

Planned

• Probably decrease to netstandard1.1.

Key notes

NU1202. PackageReference vs Reference

<ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
  <Reference Include="Microsoft.CSharp" />
  <Reference Include="Microsoft.Build" />
</ItemGroup>

<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard2.0' ">
  <PackageReference Include="Microsoft.CSharp" Version="4.6.0" />
  <PackageReference Include="Microsoft.Build" Version="15.9.20" />
</ItemGroup>

15.9.20 is last package with netstandard2.0 target support. 16.0.461 and 16.3.0 contains only .NETCoreApp2.1 and net472. That is, we can try to use Reference for net472 -> netstandard2.0.

NU1202 and netstandard1.1.

For netstandard1.1 I don't see any directly compatible packages. Thus, I'm not sure about PackageReference (any options to disable NU1202 ?) but we can also use at least Reference with some potential problems like MSB3277. For example:

<ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
  <Reference Include="Microsoft.Build" />
</ItemGroup>

<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.1' ">
  <Reference Include="Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
    <HintPath>..\packages\microsoft.build.15.9.20\lib\net46\Microsoft.Build.dll</HintPath>
    <Private>True</Private>
  </Reference>

  <!-- Use this to avoid MSB3277 - conflicts between different versions of "System.IO.Compression" -->
  <Reference Include="System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
    <HintPath>..\packages\system.io.compression.4.3.0\lib\net46\System.IO.Compression.dll</HintPath>
    <Private>True</Private>
  </Reference>
  
</ItemGroup>

---

Cc: @HamedFathi, @carstencodes

[3F]

Something wrong with tests. Different build for the same commit e9ab8b6:

• Failed: XProjectTest.PropertiesTest1 in https://ci.appveyor.com/project/3Fs/mvssln-fxjnf/builds/28065889/tests

Microsoft.Build.Exceptions.InvalidProjectFileException : The project file could not be loaded. Could not find a part of the path 'C:\snet\snet.csproj'. 

• XProjectTest.PropertiesTest1 OK! but Failed SlnTest.EnvTest1 in https://ci.appveyor.com/project/3Fs/mvssln-fxjnf/builds/28066138/tests

Microsoft.Build.Exceptions.InvalidProjectFileException : The project file could not be loaded. Could not find a part of the path 'C:\snet\snet.csproj'. 

• XProjectTest.PropertiesTest1 and SlnTest.EnvTest1 both OK now in https://ci.appveyor.com/project/3Fs/mvssln-fxjnf/builds/28066179

The same reason, that's good to isolate problem. But my pc can't reproduce even something -_- rdp is coming

[3F]

Finally this PR will not contain net46. And net472 will no longer reference modern MSBuild packages!

This is because of many additional steps with MSBuild Resolver and MSBuildLocator for trivial use.

However, user can still use custom MSBuild assemblies if needed.

I updated wiki info + added this: https://github.com/3F/MvsSln/wiki/Advanced-Features#how-to-use-modern-versions-of-msbuild-for-netfx

Summary, only netcoreapp2.1 (-> 16.3.0) & netstandard2.0 (-> 15.9.20) will reference packages.

Many, so many problems with modern MSBuild :(

I hope our wiki can help to solve all or most known problems! And I hope for 3.x when we will drop MSBuild dep.