Scope Isolation and Direct Test Execution

Test scripts are now executed in the caller's scope, instead of in Pester's module scope.  This means that the only Pester functions and variables available to the SUT will be the ones that Pester exports, and that tests won't fail if the file happens to use variables that match the names of internal Pester parameters ($test, etc.)
Note:  Some of pester's own test scripts are intended to be able to access its internal implementation details, and a mechanism for executing these tests has also been added:

& (Get-Module Pester) InModuleScope {
    Describe "Description" {
        # etc
    }
}

Test script files can now be executed directly, if desired.  However, doing so gives up most of the functionality offered by Invoke-Pester.  When executing a test file this way, you no longer get a summary of tests passed / failed, can't output to NUnit or use -Passthru, etc.
Starting work

Desirable:  Mock a command that's called from inside a module, but is not necessarily defined within that module.  The assumption being that we want to treat a script module as the SUT, at times.

Currently working for some things, but right now if you mock a function inside a module which happens to be exported, the mock is not visible from outside the module.
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.