Optionally auto-locate WebApplicationsTargetPath from an installed Visual Studio / Build Tools

[ehasis]

Split out from #103 (item 4).

Summary

To reduce friction when building with the dotnet CLI on a machine that has Visual Studio or the Build Tools (with the web workload) installed, the SDK could locate the installed Microsoft.WebApplication.targets automatically when the default WebApplicationsTargetPath does not exist.

Proposed change (opt-in)

Put the resolution behind an opt-in property (default off), e.g. ResolveWebApplicationsTargetPathFromVisualStudio. When not enabled, behavior is unchanged (and falls through to the clear error from issue #106). When enabled, resolve the targets from an installed VS / Build Tools (any edition, incl. BuildTools).

Implementation notes / constraints

• The <Import> is processed at evaluation time, before items are evaluated, so an item glob can't drive it — resolution must use property functions.
• VSWhere cannot run at evaluation time (it's an external process), so it can't be used inside the SDK to set the path. VSWhere remains the right tool for the user/CI to compute and pass VSToolsPath explicitly (relates to issue Emit an actionable error when Microsoft.WebApplication.targets / WebApplicationsTargetPath cannot be resolved #106 and Resolve WebApplicationsTargetPath to licensed version of VisualStudio build files. #104).
• Use shallow, non-recursive directory enumeration only: GetDirectories(..., AllDirectories) throws on an access-restricted subfolder and would break evaluation for every build.
• Gate on !Exists('$(WebApplicationsTargetPath)') so VS / full MSBuild and explicit overrides are untouched and pay no lookup cost.
• Known limitation: resolves a single VS/Build Tools install of any edition; for machines with several major VS versions side by side, the user sets VSToolsPath explicitly.