Summary of the new feature/enhancement

The documents folder has always been where modules user-scoped are kept, and that's always been ok, but I recently discovered some problems with this as I've been getting more familiar with Azure and my work laptop maps Documents to OneDrive. This can be problematic for a few reasons, such as OneDrive not syncing correctly or trying to restore a bunch of files from a module I just uninstalled. This is particularly an issue with larger modules (or groups of modules) such as Az.*

We can certainly wish OneDrive was better at its job, but really these files shouldn't be there - they are not documents. The user is not expected to edit them or look at them. They are more akin to application files or application data. There's no value to them being in OneDrive other than to transfer them to another machine, and that can be better achieved by having a script in OneDrive that calls PSDepend or PowerShellGet to install modules on that other machine.

I have updated my profile script to remove this path but it reappears after running install-module.

Proposed technical implementation details (optional)

1. Remove Documents\PowerShell\Modules from the $env:PSModulePath default. Select a new default path such as ~\PowerShell\Modules or $env:localappdata\PowerShell\Modules
2. Offer a cmdlet or documentation to move the existing modules to the new location, and optionally update the value of the environment variable.
3. Additionally, offer to move the existing modules and update the value of the environment variable during the install. (That way the user has the choice to make the install take care of it or do it later at a time of their choosing).