Moved fake manager creation and initial configuration into the proxy generator

This pull request solves #371 (because of the default behavior of the fake manager it also solves the bug #368).

Before this PR the FakeManager is created / attached and configured (`IFakeObjectConfigurator`) by the `FakeObjectCreator` after the proxy object was returned by `IProxyGenerator`. That's too late for the c'tor call. The `Strict()` and `CallsBaseMethods()` fake options were applied *even later* in the `DefaultFakeAndDummyManager` when evaluating the `OnFakeCreatedActions`. The same is true for the `Wrapping()` fake option.

The idea of this pull request is to encapsulate the creation and initial configuration into the new `LazyFakeManagerProvider`. The first `LazyFakeManagerProvider.Fetch(): IInterceptionSink` call initializes the fake manager and returns an interface, which is used by the proxy interceptor to notify the `FakeManager` about an intercepted call. The `IInterceptionSink` interface replaces the old mechanism using the `CallWasIntercepted` event, which was exposed by the interceptor.

The advantage of this solution is that during the execution of an constructor, the very first call to a virtual member invokes `LazyFakeManagerProvider.Fetch()` and therefore configures the fake manager just in time. If there was no virtual call during the c'tor, then a call to `LazyFakeManagerProvider.EnsureInitialized()` initializes the fake manager *after the c'tor* as it happened before this PR.

For the application of the `Strict()` and `CallsBaseMethods()` options, there are now new `OnFakeConfiguration` callbacks, which are evaluated inside the `LazyFakeManagerProvider`. The existing `OnFakeCreated` callbacks stay in the `DefaultFakeAndDummyManager` to avoid breaking changes. The handling of `Wrapping()` is now also inside `LazyFakeManagerProvider`. So in the end `LazyFakeManagerProvider` is a cohesive service, which does all the configuration steps before giving the fake instance to the user.

An interesting side effect of the new `OnFakeConfiguration` callbacks is that this also solves #365, because we can do something like this ...

```c#
A.Fake<ClassWithVirtualCallsInConstructor>(o => 
    o.OnFakeConfiguration(f => 
        A.CallTo(() => f.VirtualMethod(A<string>._)).Returns("configured value")));
```

... which would apply to calls within the constructor.


There is a new `ConstructorWithVirtualCallsSpecs` with the formalized specifications of #371.