Compile libsass for one platform at a time

[am11]

Added an inline MSBuild task, which make use of a new CoreFX API
System.Runtime.InteropServices.RuntimeInformation to obtain OS
description and architecture information, then translates into
LibSassPlatform (Win32 or Win64 etc.).

Also added ability to cross compile, e.g. Win32 on 64-bit system.

Additional OSes will be added with .NET Core support.

Added cross compile configurations for AppVeyor CI.

Fixes #47.

[am11]

/cc @nschonni

[nschonni]

I think the separate DLLs are necessary for the NuGet packaging (see the nuspec)

[nschonni]

These can probably be undone. Nothing wrong with the sort, just not related to the changes

[am11]

Agree, I ran batch formatter at the end of changes and this one was odd one out. All the rest of the code files in entire repo have usings sorted by same rule. We can do these changes separately if you prefer?

[nschonni]

I wouldn't really worry about it, but I'd usually just throw it in another commit for clarity

[am11]

Done, this change is now part of a separate commit.

[am11]

This change is good to go. The non-reflection version of task needs MSBuild15, which we will migrate to eventually for .NET Core support but that is for a later day.

[nschonni]

The pack https://github.com/sass/libsass-net/blob/master/pack.cmd and Nuspec https://github.com/sass/libsass-net/blob/master/LibSass.NET/LibSass.Net.nuspec will need to be updated if this is the way to go

[nschonni]

The layout needs to take into consideration that multiple platforms are building into the same folder. Take a look at https://github.com/sass/libsass-net/pull/52/files#diff-87bd0df6df8e00153597365c4585e239R92 for an idea on putting it at least under a "platform" folder.

[am11]

Please read the description of this PR and the associated issue.

[nschonni]

I think this looks good because one at a time make sense, but this breaks NuGet packaging , or just clobbers the folder in the case you want to build 32bit on a 64 bit OS

[am11]

👍
From slack:

yup the packaging story would be like, for windows, we will run a script to build on x64 machine which will build for all four architectures (x86,x64,arm,arm64) one at a time and place into separate directories for packing. We will compile linux and osx binaries separately before hand and place in the same build machine, the pack script will look something like pack --linux-bins=path\to\linux\bins --osx-bins=path\to\osx\bins --win-bins=path\to\win\bins or --win-bins=compile.

or to avoid doing it manually in a batch file, we can also create our custom dotnet pack command which can extend dotnet-pack: say dotnet-sassPack. That way we would be able to pack on Unix systems as well without writing a separate .sh counterpart.

[am11]

This is the whole point of this exercise to build for single platform with unified name. The DLL search path need the file in same directory. The P/Invoke requires a constant name of the DLL in the DLL search patch, which cannot be nested.

Packaging step is a separate work item, where we bring dlls from different sources (Linux, OSX boxes and/or cross-compile)