Consume projections via nupkg vs. checked-in binaries

[msft-Jeyaram]

This will establish the WinObjC.Frameworks.UWP/MSAds packages and will be consumed by projects via the nupkg

• Removing the pre-checked in binaries, headers
• Removing the pre-checked in binary package project and removing it from the main build

Fixes #2688, #2687

---

This change is 

[msft-Jeyaram]

There is two instance of WINOBJC_SDK\ usage, that is being cleaned up now :)
#ByDesign

[msft-Jeyaram]

@rajsesh-msft the projection code is generated after applying the fixes to winmd2objc (my other CRs) #ByDesign

[rajsesh]

Per offline discussion, let us not check-in the generated code. Since this doesn't need to be built every day, we could just wrap the generation step in a script or a build task. This also doesn't have to be nightly built either.

[DHowett-MSFT]

This is an interesting approach!

Do you think it should go down with the other PackageReferences?

[msft-Jeyaram]

nope, we want to avoid Frameworks.Core from consuming this package.

[DHowett-MSFT]

That doesn't mean it can't go in the same block of package references... that just means we have to keep the Condition

[msft-Jeyaram]

ah, I assumed you meant to just include it without the condition.
Consider it moved.

[DHowett-MSFT]

Indentation is odd here!

[msft-Jeyaram]

This saw random failures with NotificationQueue and filemanager tests.
Now it second run and local run seem to be fine

[msft-Jeyaram]

ping! @rajsesh-msft @DHowett-MSFT

[DHowett-MSFT]

Moderately apprehensive about using BuildingFrameworksCore to turn off the package reference instead of inserting the package reference in every project that consumes UWP.

Also, don't our internal frameworks avoid Projections now? They should be generally free of it, and we might not want to even ALLOW them to link against it so we don't accidentally reintroduce dependencies.