Provide a way to prioritize dotnet installations located in user-defined environment variables on Windows

### Description

- I have a PATH environment variable with the following two entries on Windows:: "C:\Program Files\dotnet;C:\dotnet-SDK ". Where the dotnet cli is installed.
- The first one is managed by IT, set through the system environment variables and the second one is managed by me, a developer, set through the user environment variables
- On the branch "https://github.com/Azure/azure-functions-core-tools/pull/4738", the GetMuxerPath and new Executable("dotnet", ... always return C:\Program Files\dotnet\dotnet

Essentially, what I would like the Azure function CLI (and azure function isolated worker) to do is use `C:\dotnet-SDK\dotnet` as it is the dotnet CLI that I want to use in my context as a user without privileged rights.

However, because the system environment variables are prepended to the user environment variables, this is an impossible scenario as trying to run `dotnet` or finding the dotnet CLI with Muxer will always see the system value first.

Ideally, we should be able to pass a switch to the Azure Function CLI to prefer "user" environment variables on Windows for situations where the user has a dotnet directory that they do not control in a system PATH entry and a directory they control in a user PATH entry.

When running the `func start` command, it would also be great if there was a way to automatically update the "worker.config.json" when using the dotnet cli found in the user environment variables entries. Or at least a reminder to manually update the file in the output folder of the function.

Start by reading the GetMuxerPath and Executable references mentioned in the issue and trace how func start resolves dotnet on Windows. Then inspect how worker.config.json is handled; done means a documented way to prefer the user PATH entry and either update that configuration automatically or clearly remind users to update it.

Written by the indexing model from the issue text.