Add path to global.json in SDK resolution error message when it's available

[baronfel]

SDK resolution error messages currently look like this:

Unable to locate the .NET SDK version '{0}' as specified by global.json, please check that the specified version is installed.

This is helpful, but doesn't tell the user which global.json is impacting the resolution. This is often fairly straightforward to find out (since global.json is heirarchical, it must be at or above the working directory of the process invocation), but can be outside of what the user expects.

We should incorporate the path to the global.json into this message when it is available for every message that mentions global.json, for the following named message strings (as possible) (list valid as of this commit):

• MSBuildSDKDirectoryNotFound
• MSBuildSmallerThanMinimumVersion
• NETCoreSDKSmallerThanMinimumRequestedVersion
• NETCoreSDKSmallerThanMinimumVersionRequiredByVisualStudio
• UnableToLocateNETCoreSdk
• GlobalJsonResolutionFailed
• GlobalJsonResolutionFailedSpecificVersion

Here are the docs for the native API:

//   result
//      Callback invoked to return values. It can be invoked more
//      than once. String values passed are valid only for the
//      duration of a call.
//
//      If resolution succeeds, then result will be invoked with
//      resolved_sdk_dir key and the value will hold the path to
//      the resolved SDK directory.
//
//      If global.json is used, then result will be invoked with
//      global_json_path key and the value will hold the path
//      to global.json. If there was no global.json found,
//      or the contents of global.json did not impact resolution
//      (e.g. no version specified), then result will not be
//      invoked with global_json_path key. This will occur for
//      both resolution success and failure.
//
//      If a specific version is requested (via global.json), then
//      result will be invoked with requested_version key and the
//      value will hold the requested version. This will occur for
//      both resolution success and failure.

Per these docs, if we have a 'requested version' in our result, then a global.json was present, so we should always have the path. Therefore it should be safe to have two variants of most of these messages:

• one without version/global.json path information
• one with version/global.json path information

Originally posted by @baronfel in #25733 (comment)

This is related to #24480

[nagilson]

If the user has several global.json in the hierarchy, say a/b/c and b/ contains global.json and a/ also contains global.json, do we stop the search at b? It could be something we'd want to warn but it also might be a weird repo in repo setup.

[baronfel]

It stops at the 'closest' global.json from the Current Working Directory of the dotnet process being invoked, so for VS I believe that's the directory containing the solution that's opened. For VSCode/CLI use that's usually the directory the user executed code . or dotnet from. If we really wanted to reach for the sky, we could add the CWD to the messages, but I think identifying the global.json that ended up being used is a good step on its own.

[dsplaisted]

This may be fixed by #26904, or at least fixed in some cases

[marcpopMSFT]

marking as fixed per Daniel's comment above.