Cleaned up mocking situation a bit

No longer a need to specify a switch when calling DescribeImpl or ContextImpl to control whether mock history is tampered with; it'll be based on whether the active pester state matches the one that was active when the mock was created.

This still isn't quite right, since the same command can be mocked multiple times from different places, but that should only be a problem if we try to call the Mock command from inside a unit tested call to ContextImpl or DescribeImpl, and I can't see any reason we'd want to do that.