`dotnet.findPath` could parse `global.json`

### Is your feature request related to a problem? Please describe.

`dotnet.findPath` does not parse the `global.json`.

# `paths` feature:
In .NET 10, we added the `paths` feature to global.json to specify an SDK path to use for the project. We don't respect that setting in the lookup for the dotnet host, so we may not call the correct host or create a context where that path gets used in VS Code. We could start parsing that, along with potentially setting DOTNET_ROOT for the process such that VS Code uses the runtimes in that location.

https://github.com/dotnet/runtime/pull/113512
cc @jaredpar for awareness.

# `version` feature:
In addition, customers may specify a `rollForward` value or a version of .NET that they want their project to run underneath. We also don't have an API to detect that value and determine the best version of the .NET SDK to acquire for the users, or for the version we want to find when locating an SDK for the user's project. We may want to implement that logic so it can be shared across C# and C#DevKit, amongst other extensions.

# Location of `global.json`:

The test host explorer calls into the runtime logic to find the global.json, but that is in C#. We would also need to write something to find the global.json.

### A clear and concise description of what you want to happen. Include any alternative solutions you've considered.

Potentially add the following:

- Modify `dotnet.findPath` as described above.
- Add `dotnet.globalJsonPath` to get the global json path as a `string`
- Add `dotnet.globalJsonSDKVersion` to get the latest valid .NET SDK version as specified in `global.json`, which could be called before `dotnet.findPath` and calls `dotnet.globalJsonPath` to find the path.

### Describe the solution you'd like

Define and provide 3 APIs:
- Resolve the `paths` in `findDotnet` and set `DOTNET_ROOT`
- Resolve the version in `global.json`
- Resolve the `global.json` path

### Additional context

This further consolidates us to 1 point of truth for how the SDK is resolved amongst C#DK subcomponents. Namely, the test explorer implements their own logic at this time, though they do also call into `dotnet.findPath`, there are discrepancies. This also leads to shared performance improvements and caching.