Expose all APIs to netstandard builds

[AArnott]

This exposes all p/invoke APIs to all existing builds, including portable/netstandard.
It also adds an additional win8 target which omits the store-banned APIs.

In this way, someone targeting a combination of mono, .NET Framework, .NET Core, etc. can target portable/.netstandard and still get all the Windows APIs. By omitting the APIs from win8, when an actual app targeting the Microsoft Store is built, the banned APIs will be gone and not block store compliance checks. This could mean that if a library calls one of these banned methods, that the Store app will see a missing method exception at runtime.

Fixes #382

[clairernovotny]

Are those Win8 banned API's allowed for Windows 10? I recall Win10 allowing additional API's for store apps.

Also, as Win8 requires VS 2015 and older SDK's to be present, is it "good enough" to target uap10.0 instead for this purpose?

[AArnott]

Are those Win8 banned API's allowed for Windows 10? I recall Win10 allowing additional API's for store apps.

No. The public documentation simply lists each API as banned or not without regard to which OS version. I have confirmed this with MSFT internally -- when they update the app submission compliance system to add allowed APIs, it allows them for all Windows 8/10 versions.

Also, as Win8 requires VS 2015 and older SDK's to be present, is it "good enough" to target uap10.0 instead for this purpose?

No. There are Win8 apps that consume P/Invoke.
But FWIW, I might not need to install VS 2015. So far I'm trying to install the Win8.1 SDK directly (and the UWP workload from VS2017, for my docker image). That may be all that's missing here.

[clairernovotny]

You may want to use -UseBasicParsing as I understand that avoids the legacy engine:

https://github.com/onovotny/SignService/blob/master/scripts/Install-WindowsSdkISO.ps1#L48

[AArnott]

I filed NuGet/Home#7277 to track the last remaining build issue. I have no workaround in mind yet.

[clairernovotny]

I thought that a blank GetPackagingOutputs was added to the common targets, because I recall needing that workaround with UWP in the past, so interesting to see that it's needed here? If that solves it, I can add that into the extras

[AArnott]

@onovotny Funny... I came to the same conclusion just in the last little while and filed novotnyllc/MSBuildSdkExtras#115

The GetPackagingOutputs target is defined as empty in the .NET SDK, but the win8 targets (and apparently UWP as well based on your comment) define it later in evaluation with a bunch of content.