Allow DSC/PowerShellGroup to have additional module paths

[msftrubengu]

Summary of the new feature / enhancement

By default, winget configure installs PowerShell modules under %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules. This was done to avoid conflicts when OneDrive moves the user's profile to their OneDrive's profile while winget configure is executing. If the modules are stored in the winget location powershellgroup.resource.ps1 won't be able to find the modules.

Proposed technical implementation details (optional)

A new property in the PowerShellGroup with additionalModulePaths

[anmenaga]

This scenario should be already working by setting PSModulePath env var on dsc process.
PowerShell process, started by dsc will inherit it and will use that to lookup PS modules with DSC resources.
Just remember that PSDesiredStateConfiguration module should also be accessible by the value of PSModulePath env var that you're setting.

[SteveL-MSFT]

WG discussed this and there is a scenario where the user might have a config that uses both WinPS and PS7 so it makes sense to have the same named property for both the WindowsPowerShellGroup and PowerShellGroup:

properties:
  psmodulepath: $env:PSModulePath;$env:LOCALAPPDATA\Microsoft\WinGet\Configuration\Modules
  resources: ...

In this example, the PSModulePath env var is clobbered within the group resource (thus PSDSC is still found by the default env var). The string value would be PS syntax and expanded within the group resource. We expect other language resources (ie, Python) would use their language syntax.