Add RecoverInterceptor as alternative to WithRecover

[jhump]

This adds things to the handler signature (the other properties of AnyRequest, such as Peer and HTTP method) and also provides the interceptor separately, so it can be more easily combined with other interceptors. Finally, the value of ignoring http.ErrAbortHandler is unclear and adds a potential footgun in that a handler that panics with that value may inadvertently prevent capturing metrics or other side effects that are desirable for error-tracking in the face of a panic.

WithRecover remains backwards-compatible. But it is deprecated; users should prefer the new RecoverInterceptor method and use it with WithInterceptors.

The most controversial parts of this change:

1. Using AnyRequest as the way to pass request properties, even for streaming RPCs. Does this seem like a bad idea? This was done to avoid adding a new exported type and to avoid a long parameter list. One awkwardness with this approach is having a req.Any() method that isn't useful for client and bidi streams and is awkward to populate for server streams.
2. Can be used in clients, too, to recover from panics caused by client interceptors. (It could also technically recover from panics in the framework, though hopefully those kinds of issues don't exist!) This is more complicated for streaming calls since it means needing to wrap a stream in order recover from panics in various methods (send, receive, close...).

Thoughts?

Resolves #816.