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/
No, this method is not related to the proposed feature. As stated in the PR notes, I noticed the `MockType` static class was getting cluttered with mocking strategies - so I thought it would be better to move the mocking strategies into the commands that use them. @mrinaldi did the same for NSubstitute.

Perhaps I should remove this from this PR, and submit a separate PR with this refactoring?

Also, I made it protected because I thought it would be useful to be able to derive from this command and specify a slightly different mocking strategy (e.g., resolve values lazily vs eagerly, returning a different value everytime the method is called vs return the same value every time) without having to re-write all the plumbing and reflection code.