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/
The type is currently being used by the following tests:

*   `IndexersReturnValueFromFixture` in `FixtureIntegrationWithAutoConfiguredMoqCustomizationTest` - This is an integration test. The expectation is that indexers' getters will return a value from the fixture. Adding a setter should have no effect on the outcome.
*  `SetsUpIndexers` in `MockVirtualMethodsCommandTest` - The SUT here only looks for virtual methods that are either non-void or have `out` parameters. The indexer's getter falls under this category, but the setter doesn't. The expectation is the same as the integration test.

I don't think this will cause any false positives/negatives in the future.