Stub moq properties

At the moment, AutoMoq configures a property' getter, but not its setter.
I think it would be a good idea to "stub" properties, to make them behave as normal properties. I believe this is a pretty common use case, so much so that @ploeh wrote an [article][0] about this.

To illustrate the behaviour I'm referring to:

```csharp
var sut = fixture.Create<IInterface>();
sut.Property = "Hello";
Assert.Equal("Hello", sut.Property);
```

My first thought was to simply use moq's `SetupProperty`, but I realized that the property's initial value would then have to be evaluated eagerly. This would break users' current expectations *and* the test suite (particularly, the `CircularDependenciesAreAllowed` integration test).

So I came up with a way to stub a property whilst generating its initial value lazily. In fact, if the property's setter is called before the getter, then the `context` will never be asked to resolve a value at all.

```csharp
var lazy = new Lazy<string>(() => (string) context.Resolve(typeof (string)));

mock.SetupGet(x => x.Property)
    .Returns(() => lazy.Value);

mock.SetupSet(x => x.Property = It.IsAny<string>())
    .Callback<string>(value => lazy = new Lazy<string>(() => value));
```

Notes:

* This behaviour is implemented by the `MockVirtualPropertiesCommand` class.
* While working on this PR, I realized the `MockType` static class was beginning to get cluttered with all the setup extensions and helper methods - so I thought it would be better to move the setup behaviour into their own commands (`MockVirtualMethodsCommand` and `MockVirtualPropertiesCommand`). 
* I've made these methods protected virtual so that users can reuse the commands and define a slightly different mocking behaviour if needed (e.g., resolve values eagerly, return a different value everytime the method is called).

 [0]: http://blog.ploeh.dk/2013/04/05/how-to-configure-automoq-to-set-up-all-properties/
Thank you for clearing that up.

The more code in a pull request, the harder it is to review. The harder it is to review, the longer it sits in the review queue.

Additionally, if a pull request contains *n* changes, the reviewer may agree with *n - 1* changes, but have an issue with 1 change. This will hold up the entire pull request.

On the other hand, if instead of a single pull request with *n* changes, there had been *n* pull requests, each with a single change, the *n - 1* pull requests could immediately have been accepted and made available to the community, and discussion could have proceeded about the single pull request where the reviewer identified issues.

In my experience, attempts to retroactively 'repair' a pull request by removing changes from it again, tends to clutter the version control history - it also tends to make it even harder for the reviewer to perform the review.

For these reasons, I'd much prefer new, separate pull requests that each only address a single issue.