Allow specifying SDK search paths in global.json

[elinor-fung]

• Parse optional properties in global.json:

  {
      "sdk": {
          "paths": [ "path/to/sdk/root", "$host$" ],
          "errorMessage": "<message>"
      }
  }

  • paths can be absolute or relative to the global.json. $host$ is a special value indicating the running dotnet path
  • errorMessage is shown on SDK resolution failure (instead of the host's default SDK resolution error message).
• Make hostfxr search for SDKs with custom paths if specified and error out with custom message if specified
  • dotnet <command> - global.json based on process working directory, runs command using resolved SDK respecting global.json paths
  • hostfxr_resolve_sdk2 - global.json based on working directory argument, returns resolved SDK respecting global.json paths
  • --info and --list-sdks - global.json based on process working directory, prints found SDKs respecting global.json paths
  • hostfxr_get_available_sdks and hostfxr_get_dotnet_environment_info - global.json based on process working directory, returns found SDKs respecting global.json paths
• Update error and tracing messages to include information about configured search paths

Part of https://github.com/dotnet/designs/blob/main/proposed/local-sdk-global-json.md.
SDK needs to be updated as well. It currently assumes that its process is the SDK root path, which would no longer be the case if the SDK is resolved via a custom path. It needs this for launching sub-processes for build, run, etc.

Contributes to dotnet/sdk#8254

cc @dotnet/appmodel @jaredpar @rainersigwald

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

I switched this to just be for frameworks, since callers of this for SDK locations always disable multi-level lookup, so all this did was add dotnet_dir (if non-empty) to locations.

[am11]

        "paths": [ "path/to/sdk/root", "$host$" ],

Are these paths absolute? If so, would it make sense to additionally support repo-relative paths using Git’s pathspec? See: https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec.

Specifically:

• :(top)/tools/.dotnet in Git pathspec means "relative to the repository root." Here, top is a special keyword, and :(<token>) denotes a pathspec.
• :/tools/.dotnet is a shorthand for :(top)/tools/.dotnet.

For example, when positioned in runtime/src/libraries, running git grep foo searches within src/libraries (relative to the current directory). However, using git grep foo ':/' or git grep foo ':(top)' searches across the entire repository without changing directories.

In the context of global.json, :/ could similarly mean "relative to global.json"—inspired by Git pathspec, which developers can relate to. It wouldn’t necessarily refer to the actual source control root.

[elinor-fung]

They can be absolute, but I expect the common use case is relative. If the path is not rooted, we treat it as relative to the global.json. I think that is a simple enough distinction without needing a pathspec or special keywords/token.

Made me realized I missed adding a test for that case (thanks!) - will add one.

[AaronRobinsonMSFT]

[elinor-fung]

/ba-g Failure is #113580