Provide better diagnostics to non-admin users of 'integrate install'.

[dubejf]

Building up on #1034, this PR treats failures as warnings in integrate_install_msbuild14().

1) Happy path

.\vcpkg.exe integrate install
[green] Applied user-wide integration for this vcpkg root.
CMake projects should use: "-DCMAKE_TOOLCHAIN_FILE=..../vcpkg/scripts/buildsystems/vcpkg.cmake"

All MSBuild C++ projects can now #include any installed libraries. Linking will be handled automatically. Installing new libraries will make them instantly available.

No change. This is fine.

2) With %LOCALAPPDATA%\vcpkg set as read-only

.\vcpkg.exe integrate install
[red] write_contents("C:\Users\...\AppData\Local\vcpkg\vcpkg.user.props"): permission denied

No change. This failure mode seems unlikely, and the simplicity of a hard error is reasonable to me.

3) Declining UAC elevation to modify MSBuild14 files under to C:\Program Files (x86)\

.\vcpkg.exe integrate install
[yellow] warning: failed to install system targets file to C:\Program Files (x86)\MSBuild/Microsoft.Cpp/v4.0/V140/ImportBefore/Default/vcpkg.system.props
[yellow] warning: Integration was not applied.
CMake projects should use: "-DCMAKE_TOOLCHAIN_FILE=...../vcpkg/scripts/buildsystems/vcpkg.cmake"

All MSBuild C++ projects can now #include any installed libraries. Linking will be handled automatically. Installing new libraries will make them instantly available.

For users only interested in VS2017 and later toolchains, this is more informative than the current version, which fails with either

[current version]
.\vcpkg.exe integrate install
[yellow] warning: Integration was not applied.

or

[current version]
.\vcpkg.exe integrate install
[red] failed to install system targets file to C:\Program Files (x86)\MSBuild/Microsoft.Cpp/v4.0/V140/ImportBefore/Default/vcpkg.system.props

IMO the text in the new version should be improved ("Integration was not applied" should talk about partial success, "All MSBuild C++ projects..." is not strictly true here), but I didn't want to introduce new strings.

What do you think?

[dubejf]

@microsoft-github-policy-service agree

[ras0219-msft]

Sorry for the piecemeal review -- I didn't review closely enough the first time.

In your proposal, it seems like your intent is to keep all the "external" behavior the same (failures are still failures, successes are successes), but just change the messages displayed to the user to be more helpful. In that case, we need the exit codes to remain the same so that scripts/CI systems will react in the same way.

Thanks for the PR! It does look good to me after the exit code issue is resolved.

Robert convinced me otherwise