Fortunately for us, @kkozmic already wrote the logic behind this in
d3ec3bf (in the form of `DelegateProxyGenerator`), so it's mostly a
matter of creating a more convenient API for it in `ProxyGenerator`.

The tests in there are really about `DelegateProxyGenerator`.

Create a new fixture (having the same name as the one we previously
renamed) with tests for the new `CreateDelegateProxy` functionality.

The tests targeting `in` parameters are currently failing. We'll need
to fix this in subsequent commits.

It turns out that the tests from the previous commit fail due to a bug
in the runtime (`in` parameters + generic types cause `ldtoken` IL to
reference a non-existent method) that we've previously encountered.

Skip these tests and replace them with similar ones that do not rely
on a generic delegate type. These will pass just fine.

... and tests verifying that the proxy calls (interceptors and) the
target as it should.

Note that these tests don't opt into the same testing pattern used
with other proxy kinds; i.e. we don't expand the `ProxyKind` enum be-
cause the tests using it often wouldn't work for delegate proxies.
This is because they are more limited than other proxy types and don't
support most of the usual things like hooks or additional interfaces.

These tests attempt to document what `IInvocation.Method` and `IInvoc-
ation.MethodInvocationTarget` should be for the various proxy types.

These tests essentially document two facts:

 * `IInvocation.Method` points to the corresponding method in the
   proxied type.

 * `IInvocation.MethodInvocationTarget` points to the method that will
   get invoked when invocation proceeds to the target, or `null` if
   there is no target.

No tests are added for `IInvocation.GetConcreteMethod()` and `IInvoc-
ation.GetConcreteMethodInvocationTarget()`. These deal mostly with
open generics and don't appear to be relevant for delegate proxies.

As requested during the review period for `CreateDelegateProxy`.