Better handle dependency mismatch between host and core tools

_originally posted by @Francisco-Gamino in https://github.com/Azure/azure-functions-core-tools/pull/2987#issuecomment-1069406086_

> The Core Tools build for Integration testing was failing for sometime because the Host referenced `Microsoft.ApplicationInsights` version `2.20.0` while the Core Tools referenced version `2.18.0`. The workaround was to create a new branch and update `Microsoft.ApplicationInsights` to `2.20.0`.
>
> Going forward, would it make sense to have a similar script like https://github.com/Azure/azure-functions-core-tools/blob/v4.x/validateWorkerVersions.ps1 with all the packages that are referenced in the Host and the Core Tools, and run it every so often to keep the packages updated? Thoughts?

Reply by me:

> Tbh, as a non-.NET developer I'm not that familiar with how nuget and dependencies are handled. I've heard of "nuget dependency hell", but I have not had much experience with it until now.
>
> In Node.js, people normally specify ranges of a dependency by default instead of a specific version. I'm pretty sure dotnet/nuget supports ranges, though, right? Any issue if I changed "2.20.0" to "2.*"? We care about the worker versions (why the script is necessary), but do we really care which minor version we get for app insights? For some reason, I don't see people use ranges a lot in .NET and I'm not sure why.

Start by reviewing validateWorkerVersions.ps1 and the package references used by the Host and Core Tools. Determine how dependency mismatches such as Microsoft.ApplicationInsights 2.20.0 versus 2.18.0 are currently detected, then define what an automated check should cover and how completion would be verified.

Written by the indexing model from the issue text.