Mocking Updates

The -ModuleName parameter of the Mock function now specifies the target scope of where the Mock will exist.  In other words, this is where the code that CALLS the mocked command lives, but is not necessarily the module where the mocked command was originally defined.

This allows us to mock calls to external commmands from within a module.  You can Mock the same command multiple times in different module scopes, if you like.  If a mock exists in the same scope where the command was called, that Mock will be used first, before attempting to use any other accessible Mock (in the Global scope, if one exists.)

As part of this update, I commented out code that allowed for a syntax of (Mock Module\Command), because it's a bit confusing, and could possibly get in the way of future expansion.  In that syntax, "Module" would refer to the scope where the Mock exists (the calling code), but Module\Command syntax looks like you're trying to Mock calls to "Command" in "Module", from somewhere else.
Should we ever figure out a way to support mocking of fully-qualified calls, we'll still have this syntax available.
InModuleScope changes

Changed InModuleScope from being an internal, Pester-only feature to an exported function that can be used to test the internal workings of any module.

Because this is starting to overlap the Scope Isolation and Module Mocking updates, they're being merged into a single branch and PR.