Resolve dll loading conflict during help generation

[isra-fel]

Description

Unblock #12528

IotHub and DeviceProvisioningServices are depending on Newtonsoft.Json 12.0.3, however our tools are using 11.0.2. This caused dll loading conflict during help generation in static analysis.
Solution is to use a custom ALC (assembly loading context) to load each module and their dependencies, so that they won't conflict with each other or common tools.

(No changelog required because it's only code change to tools)

Checklist

• I have read the Submitting Changes section of CONTRIBUTING.md
• The title of the PR is clear and informative
• The appropriate ChangeLog.md file(s) has been updated:
  • For any service, the ChangeLog.md file can be found at src/{{SERVICE}}/{{SERVICE}}/ChangeLog.md
  • A snippet outlining the change(s) made in the PR should be written under the ## Upcoming Release header -- no new version header should be added
• The PR does not introduce breaking changes
• If applicable, the changes made in the PR have proper test coverage
• For public API changes to cmdlets:
  • a cmdlet design review was approved for the changes in this repository (Microsoft internal only)
  • the markdown help files have been regenerated using the commands listed here

[isra-fel]

Assembly.LoadFrom() will load the dll into the default ALC, so the dlls may conflict.

[isra-fel]

The assembly resolving logic is the same as before. I just use AssemblyLoadContext.LoadFromAssemblyPath() to load the dll into individual ALCs

[isra-fel]

Root cause: we depend on Microsoft.PowerShell.SDK 6.1.0, which depends on Newtonsoft.Json 11.0.2.
Before loading the dll, we run a powershell script to read the psd1 file, which loads powershell sdk as well as newtonsoft.json 11.0.2, causing other versions not able to be loaded.