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.  This syntax can also bee used to execute test code in the scope of another module, if that is useful.

    InModuleScope Pester {
        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.

Mocking code has been revised to be aware of the scope of the code being tested.  Mock -ModuleName has been changed slightly; it now allows you to mock CALLS to any command from inside a module.  This overlaps slightly with the InModuleScope command; the following two constructs have the same effect:

    Mock -ModuleName TestModule InternalFunction { 'I am the mock.' }

    InModuleScope TestModule {
        Mock InternalFunction { 'I am the mock.' }
    }

The difference is that when using InModuleScope, you can execute internal module functions directly.  This can be used to perform unit tests on a module's implementation details, instead of only being able to access its public API.

Module mocks can now be used to mock a call to any command from inside a module, instead of only mocking a module's own internal functions.  For example:

    Mock -ModuleName TestModule Start-Sleep { 'Sleep is for the weak.' }
More mocking fixes

Per conversations with nohwnd, module mocks should be isolated from each other.  The current implementation allows for some bleed between the two modules if, for some strange reason, we mock the same command names from two scopes at once.

Added some new tests to reflect this.  Fix code coming next.
Mocking update (module scope separation)

Mocks in different modules now have completely separate records in $mockTable (denoted by a key of "Module||Command"), instead of sharing a Mock record, but having Blocks in separate scopes.
Code that operates on each Mock table record is now very nearly the same as it was before the Scope Isolation branch started, with a little bit of script block scope injection added.
It gets its own Pester scope

Mocks and Test Drive content created within "It" blocks are now cleared.

Mock call history used to reset back to zero at the end of any Context or Describe block; with the introduction of It scopes, call history is now only cleared for Mocks in the same scope.

Note:  One point here is still a bit awkward.  A mock's "scope" is set when the first mock for a particular command / module combination is created, and all calls to that module / command share a call history.
If the mock is overridden in a child pester scope, calls to that lower mock are still maintained in the call history.
We can probably change this so call history saves the Block's scope instead of the Mock's scope, which would correct the problem.
Added failing tests

Added tests to cover the upcoming functionality of having call history linked to mocks in a particular scope, instead of all lumped together for as long as a mock of a particular name exists.
Mock Call History scoping

Calls to mocked functions are now assigned a Scope according to the block which was matched and executed.  When exiting a Pester scope (It, Context, Describe), mocks and calls to mocks in that scope are removed, while the call history of higher level mock blocks is retained.
Small fix for PowerShell 2.0 compatibility

Added @() operator so that foreach loop wouldn't execute once with $null in PowerShell 2.0
PowerShell 2.0 compatibility fix

Calls to Clear-TestDrive in "It" and "Context" were using syntax that doesn't work in PowerShell 2.0.
Test update for PowerShell 2.0 compatibility

WarningVariable wasn't working properly in PS 2.0 tests for some reason, resulting in a false failure.  Changed it to work by mocking and verifying calls to Write-Warning instead.
StrictMode compatibility

All pester test files now have "Set-StrictMode -Version Latest" as their first line, so we're testing this in each release.

Mock.ps1 code related to executing parameter filters has been updated to be StrictMode compatible.
Removed comment

Comment was misleading; this works with StrictMode even if no cmdletbinding / paramblock information is passed in.  The ScriptBlock produced by [scriptblock]::Create() appears to work either way.  (Maybe because it's not inheriting the StrictMode setting from the scope that called Create(); not sure.  Either way, it works.)
Direct Test Execution fix

Recent mocking changes broke this (mocktable / mockcallhistory initialization took place in Invoke-Pester).
Test fix for direct execution

Mock tests had a problem if the test file was dot-sourced into the Global scope.
One of the dynamic test modules which is imported and later discarded contained an
exported function with the same name as one of the other functions in the test
script.  When the module is removed under these conditions, the original global
function is not restored.  This is not a defect in Pester; it's just how PowerShell
works.  Renaming that module function resolved the problem and allows the Mock
tests to execute, even when pressing F5 in the ISE (which is the equivalent
of dot-sourcing the test script.)
Changes to mock call history behavior

Per conversations with nohwnd, we're changing how mock call history is tracked and checked, as compared to the
previous commits in this branch.

Instead of having Assert-MockCalled's -Scope parameter target the scope of the mock's definition, it will instead
refer to the Pester scope that was current at the time the call to the mock was made.  This allows for blocks like
the following to be arranged in any order, and still work:

    Mock SomeCommand { }

    It 'Reports one call' {
        SomeCommand
        Assert-MockCalled SomeCommand -Exactly 1
    }

    It 'Reports one call' {
        SomeCommand
        Assert-MockCalled SomeCommand -Exactly 1
    }

    It 'Reports one call' {
        SomeCommand
        Assert-MockCalled SomeCommand -Exactly 1
    }

Because Assert-MockCalled will default to checking for calls in the current scope, each of those calls to
Assert-MockCalled will succeed.  This behavior can be overridden by passing Assert-MockCalled -Scope Context
or -Scope Describe, which will then tally up all the calls in the specified scope or lower.  (Describe gives you
all of the calls at the Describe, Context and It scope, etc.)

When you exit a particular scope, any entries in the call history are promoted up to the parent scope, leaving a pristine,
zero call history in place every time you enter a new Context or It block (while the parent scope still remembers the calls
made in previous Context / It blocks which are now finished.)

Also came across a direct test execution / Strict Mode bug for PowerShell 2.0, and corrected it.  Tests still fail when
the tests are dot-sourced in PowerShell 2.0, and I'm not sure why yet, but it's probably not important.  We are still
all green in PS2.0 when Invoke-Pester is used, and when the scripts are run without dot-sourcing.  The only annoying
thing will be that tests might fail if a user opens a test script in the 2.0 ISE and runs it with F5, and I don't think
we really need to try to fight with the scope and strict mode rules to get that particular edge case working.
Mock call history change

Entries in $mockTable are now only cleared when there is no parent scope (which today, means when we exit a
Describe block.)  This way the call history of mocks defined in lower scopes are maintained, and can be checked
with Assert-MockCalled.

Assert-VerifiableMocks still requires the mock to be "live", though, since the Verifiable flag is associated with
the blocks that are cleared as we exit each Pester scope.
Update to Invoke-Pester output

When user specifieds a value for -TestName, this is added to the initial "Executing all tests in..." message.
Documentation updates, small bug fix and code cleanup

Updated help for Assert-MockCalled to reflect new ModuleName and Scope parameters / behavior.

Revised some code and fixed an output bug in Assert-VerifiableMocks
More documentation updates
Reported times are now more accurate

Fixes Issue #47 .  PesterState object now maintains a running Stopwatch, and whenever a test result is added,
it bases the reported time for that test on the elapsed time since the last report, instead of only measuring
the time taken for the execution of each "It" block (and ignoring all the time spent in Context and Describe).

This does have the effect of slightly inflating the reported time spent on the very first test of each Describe
or Context block, since that's the one that winds up eating the overhead of setting up and tearing down scopes,
mocks, test drives, etc, but this is still preferable to having the entire test suite report that it's running
in a fraction of a second, even though anyone paying the slightest bit of attention can see that it's taking
10-20 times that long to finish all the tests.
Changed default behavior of Assert-MockCalled

Command now identifies all calls to the mocked command by default (scope setting of "Describe").
If the test wants to narrow down the focus of the check, it can pass in -Scope Context or -Scope It.

This should result in fewer calls to Assert-MockCalled needing to specify a -Scope parameter (since
the most common use case should be to check for calls outside of the It block anyway), and will hopefully
also result in less impact to existing test scripts when this major version update is complete.