Add memento capture to IInvocation (aka async interception groundwork)

[stakx]

This is the smallest change I can think of that might just be sufficient to enable people to write async interceptors. While technically still a breaking change (it adds a new member to the pre-existing IInvocation interface) it's a comparatively minor one, and it does fix the same unit test from #429.

What problem does this PR attempt to solve? As soon as an async continuation is set up in an interceptor's Intercept method (e.g. by means of an await), interception starts to regress back to the caller and the invocation's currentInterceptorIndex starts getting decremented—this is why invocation.Proceed() will no longer work in the async continuations: it will end up proceeding to an earlier interceptor instead of to the next one.

I therefore tried to find a way to make currentInterceptorIndex modifiable without exposing it, and ended up with the Memento pattern.

While I think completely removing Proceed (and currentInterceptorIndex with it) from AbstractInvocation would possibly be the cleaner solution in the long term, it would also trigger the need for a fairly large breaking change in DynamicProxy's Intercept / Proceed API, and I'm not sure we're ready for that.

I don't expect this to get merged, as we probably don't really need a generic memento facility for invocation objects 😜, but I am still curious what others think about this approach.

/cc @JSkimming, @brunoblank

[stakx]

Closing for the time being... while this doesn't expose AbstractInvocation.currentInterceptorIndex, it still makes it possible to mess around with internals that noone should ever notice. I think I can do one better.