existingPath Setting is not always respected on C#, CDK

# Explanation

We sometimes get user reports that the 'existingPath' setting for the .NET Runtime extension does not work, even though it does seem to work on our end, and we have never gotten any further information about how it does not work. Specifically, this option:
```json
"dotnetAcquisitionExtension.existingDotnetPath": [
{
"extensionId": "ms-dotnettools.csharp",
"path": "C:\\Program Files\\dotnet\\dotnet.exe"
}
]
```

There is confusion there because it needs to be set for csharp as well as c# devkit. But there is another issue which is present in both extensions that I realized is very confusing to users. That is because the setting is ignored if there's a .NET on the PATH.

https://github.com/dotnet/vscode-csharp/blob/efd9e7f332d73063a34fbb72cbca48aba6ee3e4b/src/lsptoolshost/dotnetRuntimeExtensionResolver.ts#L59

Taking a look at the code, we can see for both C# and C# DevKit that the dotnet on the PATH is used over this setting. I think its a good idea to use the .NET on the PATH if its available, but if someone specifically gave us a different dotnet path and we still used this one, it's a bit confusing. I realized this because of a customer who was confused why the setting on the PATH was not being used and thought it didn't work. It was because of this.

Admittedly, people may not understand that they would need to use a different host, which would be what actually picks the .NET runtime and SDK to use. But, its still a UX improvement in my eyes.

# Proposal

We should write a command API for DevKit and C# to call that tells CDK and C# what the existingPath setting is on our extension for them. If its set, c# and CDK should use that before it uses the .NET on the PATH, to eliminate this confusion.

Let me know your thoughts, if we agree then I will go do that work item from the .NET Install Tool end.

cc @dibarbet @arkalyanms @AArnott @webreidi @baronfel @leslierichardson95