AutoMoqBoostCustomization

`AutoMoqBoostCustomization` is a customization that builds on top of AutoMoq's `AutoMoqCustomization`.

`AutoMoqBoostCustomization` uses the existing `MockPostprocessor` to allows mocks to be retrieved from a fixture, and adds its own `MockSetup` to automatically setup mocks created by the post-processor before returning them to the client.

The mock's members (methods/properties/indexers) will be set up in such a way that return values will be retrieved from a fixture (see examples below). Also, if a method contains any "out" parameters, the value for the outcome of these parameters will also be fetched from a fixture.

`MockSetup` is composed by a collection of `IMockInitializer`s, each of them responsible for setting up certain members of the mock object. Currently, 2 initializers are provided (although the client is free to define his/her own initializers):

#### SealedPropertyInitializer

This initializer will inspect a mock's members and check for any properties that cannot be setup by Moq, i.e., any sealed/non-overridable properties.

Each of these properties will be setup in the following manner:

    mock.Object.Member = fixture.Create<TMember>();

#### VirtualMethodInitializer

This initializer will inspect a mock's members and check for any methods that can be setup by Moq, i.e., any virtual/abstract/non-sealed methods.

Each of these methods will be set up in a manner similar to this:

```csharp
//setting up "public int Method(string p1)"
mock.Setup(m => m.Method(It.IsAny<string>()))
    .Returns(() => {
          var result = fixture.Create<int>();            //retrieve value from the fixture (lazily)
          mock.Setup(m => m.Method(It.IsAny<string>()))
              .Returns(result);                          //reuse this value the next time the member is invoked
          return result;
    });
```

If the method being set up contains any "out" parameters, then the setup becomes:

```csharp
//setting up "public int Method(string p1, out bool p2)"
//value for the "out" parameter must be retrieved eagerly
var outParameter = fixture.Create<bool>();        
mock.Setup(m => m.Method(It.IsAny<string>(), out outParameter))
    .Returns(() => {
          var result = fixture.Create<int>();
          mock.Setup(m => m.Method(It.IsAny<string>(), out outParameter)))
              .Returns(result);
          return result;
    });
```

In order for a method to be eligible for setup, it needs to:
* be overridable (self-explanatory);
* either be non-void *or* have "out" parameters.
    * If the method is void and has no "out" parameters then there is nothing worth setting up.
* not have ref parameters;
    * due to a limitation in Moq (see the third example in the [Quickstart][2]), a setup for a method with a "ref" parameter will only be matched if the variable used to setup the method is the same as the one used to call the method. Since the setup and the invocation take place in completely different scopes, automatic setup of a method with "ref" parameters is therefore impossible.
* not be generic;
    * automatic mocking of generic methods isn't feasible either - we'd have to antecipate any type parameters that this method could be called with. Note that methods that belong to a generic type, but don't introduce any generic type parameters of their own are *not* considered generic themselves and can, therefore, be automatically setup.
    * in order to simplify manual mocking of generic methods, the `ReturnsUsingFixture` public extension method is available. Usage: 
    ```csharp    
converter.Setup(x => x.Convert<double>("10.0"))
             .ReturnsUsingFixture(fixture);
    ```



Note that properties and indexers are also implemented as methods (e.g., `get_Age()` and `get_Item(Int32)` respectively). As follows, the `VirtualMethodInitializer` will also set these up.



**Notes**: 
* The `ReturnsUsingFixture` extension method was added to the `MockType` static class. This class was made public, but all other methods remain internal.
* The extension method, the `IMockInitializer` interface and the `Setup` method on both implementations of this interface were marked with `[CLSCompliant(false)]` because their arguments are not CLS compliant. Let me know if there is a more desirable approach to this issue.
* This started out as a separate project entitled `AutoMoq.Boost`, available [here][1]. This project will be marked as "migrated" and discontinued once the pull request is accepted.

 [1]: https://github.com/dcastro/AutoMoq.Boost
 [2]: https://github.com/Moq/moq4/wiki/Quickstart

I don't think this behaviour should be the default behaviour. Although it seems to be what several people expect of AutoMoq, it implicitly endorses API designs that violate the Law of Demeter, because it almost becomes too easy to have mocks returning mocks returning mocks, ad infinitum.

As an explicit opt-in feature, I think this is a great feature, but I'd like to keep AutoFixture opinionated enough that you do get a little slap over your fingers if you try to design your APIs like that, and *then*, if you decide that that's what you want to do, you can add this feature.

Just like the default recursion behaviour being that circular references is evil, but still enabling you to choose a different behaviour.

This is the reason I'm asking about a separate, descriptive name for this feature.