Delegate currying refactorings

For valid delegates, the MethodInfo returned by System.Delegate.Method does not necessarily match the signature of the delegate. For example, in .NET 3.5+, the C# compiler allows you to take extension methods such as:

```
int Enumerable.Count<T>(this IEnumerable en)
```

And bottle them up like so (assuming Enumerable was imported via a using):

```
var en = ...; // some IEnumerable
Func<int> counter = en.Count; // actually binds to Enumerable.Count
```
As you can see, even though the underlying Enumerable's public signature takes in a parameter, it's surprising that it can be captured by a delegate that does not accept parameters. Capturing "instance-like" invocations of extension methods is probably very uncommon for affected Moq scenarios (Callback(...), Returns(...), VerifySet(...)).

In addition, certain DLR code generation strategies also can cause a lambda to be emitted with an extra ignored "curried" parameter. As it turns out, invoking these signatures is noticeably faster (~33% time shavings off of invocation overhead). This is very likely because delegates already have to account for invoking instance methods - especially for the classic mainstream scenario of delegates invoking event handlers.

As it turns out, the next generation .NET Compiler Platform ("Roslyn") compilers are also exploring the use of delegate currying techniques.

These changes allow for Moq to be currying-aware in a backwards compatible way (with older compiler versions).

This fixes the failed Moq unit test cases when Moq/unit tests are compiled with Roslyn, as well as adds an extension method testcase to demonstrate the repro against pre-Roslyn C# compilers.