.NET Framework 4.0 Targeting to address partner integration challenges

Per challenges integrating with partner assemblies and services, and the newly discovered inability to use NuGet assembly binding redirects with PowerShell scripts, the most stable choice here is to revert to .NET Framework 4.0 - the same as prior PowerShell releases.

Decision was made in conjunction with the storage team when analyzing the overall results and status from the Thursday night integration attempts to use a storage private build instead of the official storage bits. In order to prevent regressing current scenarios (storage cmdlets, marketplace cmdlets, etc.) this was the call.

This therefore keeps:
- Same .NET 4.0 target as previous release, text matrix, NuGet packages as previously used
- Same storage library 2.0.5.1 bits + Data Movements binary (unable to use binding redirects)
- ODataLib 5.2 + dependencies (same as previous release)
- Marketplace WCF + OData service reference that was unable to move forward

This introduces a refactored, .NET 4.0-compliant project configuration (the Plan B for landing AD integration; same source as before)
- .NET 4.0 targeted management library alternative

Unfortunately the week's firedrill to move to .NET 4.5 will have to be attempted at another time when there's appropriate runway and planning to land all the components. We'll have a good set of post mortem conversations for sure.

CI server is passing 100% green on this, effectively these are the runtime changes to keep the various bits still working, same as earlier in the week before the communication to use 4.0.3-4.5.