Remove expression execution from Setup and Verify & make them recursive

[stakx]

When Setup and Verify are given "recursive" / "fluent" expressions, e.g.

mock.Setup(m => m.Foo.Bar.Baz.DoSomething())...;

... then up until now, Moq simply compiled that expression & executed it with DefaultValue.Mock temporarily enabled to set up the mock object graph leading up to baz.DoSomething. As elsewhere, expression compilation and execution has a variety of side effects (e.g. #699), so it would be good to avoid it.

We can actually do something fairly simple: We break apart the given expression into several setup expressions:

• m => m.Foo
• (foo) => (foo).Bar
• (bar) => (bar).Baz
• (baz) => (baz).DoSomething()

... then set these sub-expressions recursively: The original mock sets up the first expression to yield an inner mock of type IBar, who will set up the next expression to return an inner mock of type IBaz, and so on.

Recursive verification by Verify works similarly, except that it never sets up inner mocks that aren't already there. Instead, it has one additional rule: The absence of an inner mock is treated as a verification error if the expected call count on an inner mock's method is anything other than Times.Never.

We can only do this change for Setup and Verify methods that are already expression-based; i.e. this excludes SetupSet and VerifySet. We'll deal with those in a later PR.

Fixes #699.

[stakx]

In addition to the review comments below, the new lambdaExpression.Split() method could use some additional documentation, as its expression-rewriting code might not be trivial to understand. Also, it lacks some unit tests about the extracted methods and arguments.