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/
Wouldn't that be just moving the coupling elsewhere? [Here](http://blog.ploeh.dk/2013/04/08/how-to-automatically-populate-properties-with-automoq), `AutoPropertiesCommand` is coupled to the customization, whereas I coupled it to `MockVirtualPropertiesCommand`. 

Is there an advantage in coupling `AutoPropertiesCommand` to the customization instead? 
In my opinion, the customization should be responsible solely for instantiating the pieces of the puzzle and adding them to the fixture, not for defining which properties need set.