force set Condition="false" on Microsoft.WebApplication.targets

[brettfo]

The import $(VSToolsPath)\WebApplications\Microsoft.WebApplications.targets can never be resolved in the updater as it runs in the Linux Docker container. Under most conditions, the $(VSToolsPath) property will not be set so this isn't an issue (n.b., the Condition="'$(VSToolsPath)' != ''" attribute), but some project files do set it, which makes it impossible to skip importing that targets file through the normal means.

The fix in this PR is to always set Condition="false" on that import node and then restore it after the run to its original state. An equally valid fix would have been to remove/re-add the entire <Import> node, but re-inserting the original node at the correct location is difficult; instead it's much easer to find the node and modify (or remove, etc.) the condition attribute.

It is also a possibility for the code owners to update their .csproj to use the SDK-friendly MSBuild.Microsoft.VisualStudio.Web.targets NuGet package. That would allow the updater to still run, but requires non-trivial permanent changes/migrations to their project file and that's outside the scope of what we're trying to accomplish: an in-place package update with a minimal diff.

Another potential fix would be to place an empty Microsoft.WebApplication.targets file in the Docker image. This would certainly work at runtime and require less code, but would not be unit-testable.

I split up the behavior into parts that I thought made the most sense.

1. Only the smallest call into our NuGet runner is wrapped with the WebApplicationTargetsConditionPatcher. I used IDisposable for everything to ensure the original file is always restored to its correct state.
2. The web application patcher only knows how to find the requisite <Import> node and set/reset the condition attribute, nothing more.
3. That patcher builds on top of a more generic XmlFilePreAndPostProcessor class. This is the one that parses the XML and calls the appropriate PreProcess and PostProcess functions.

All of the code was done this way so that if we have to expand the pattern of targets files that can't be imported, we can do very targeted fixes with the minimal amount of mess. Ideally this will be the only special case we need, but in all reality, we may end up with one or two more in the future.

Fixes #8532.

[ryanbrandenburg]

I like this shape, I think it makes it relatively easy to create a couple of similar Patchers and group them together into an aggregator.