Fix dotnet runtime resolution for external acr provider

[sarsharma]

This pull request refines the version resolution logic for .NET Core platform detection and installation, especially when using ACR (Azure Container Registry) providers. It clarifies how runtime and SDK versions are resolved depending on which provider is enabled, and updates the test suite to ensure the new logic is validated. The main focus is to ensure that version mapping and fallback behaviors are correct and transparent.

.NET Core version resolution logic:

• When the External ACR SDK provider is enabled, the SDK version is taken directly from the provider, and the runtime version is only minimally processed (not fully resolved against the version map). [1] [2]
• For Direct ACR, the runtime version is resolved on demand using the version map to ensure the tag is exact (e.g., "10.0.4" instead of "10.0"). If resolution fails, the process skips Direct ACR and falls back to the next provider.
• If neither ACR provider is available or successful, the normal version resolution path is followed: the runtime version is fully resolved using hierarchical rules and the version map, then the SDK version is determined.

Test updates:

• Unit tests have been updated to use more realistic version pairs (e.g., "3.1.32" for runtime and "3.1.426" for SDK) and to verify that the correct versions are passed to providers and set in results. [1] [2] [3] [4] [5]
• Tests now assert the expected behavior for version resolution and fallback, including the distinction between hierarchical-only and fully resolved runtime versions, depending on the provider path taken. [1] [2]