Compound block expectations

This is a spike for #552.  Feedback wanted.

The basic solution here is pretty straightforward:

* For one matcher (let's call it the "outer" matcher), rather than passing it the actual block, pass it a new block that performs matching against the other matcher (call it the "inner" matcher) using the actual block.
* This causes the real block to be executed when the outer matcher calls our intermediate block, making things work properly.

This straightforward approach didn't work for some of our block matchers, though:

* `raise_error` and `throw_symbol` cannot be the outer matcher, because when an error is raised or a symbol is thrown it jumps out of the inner matcher's `matches?` (since it doesn't expect a raise or throw).  They must be the inner matcher, regardless of what order the matchers were chained in.  To make this work, I added a new method to the matcher protocol, `block_can_be_wrapped_for_compound_expression?`. We use this to figure out if a particular matcher must always be used as the inner matcher.
* The `yield_xyz` matchers pass an argument (the yield probe) to the `expect` block, which gets a little hairy when the yield matcher is the outer matcher.  The solution I came up with is to wrap it in an extra proc that receives an forwards the args on to the inner proc.

There are also some open questions:

* I really hate the `block_can_be_wrapped_for_compound_expression?` method name but couldn't come up with a better name for it.  Any ideas?  Also, when the method is not defined, it defaults to `true` (as the other block matchers allow the block wrapping), but it feels inverted to me to have the optional method be treated as `true` if not defined.  We should find a wording that would allow us to default it to `false` but I can't think of a good method name for that.  Alternately, we could assume all block matchers can't be wrapped and opt-in to the ones that can (`change`, `yield_xyz`, `output`).
* How should it behave when two matchers are used that both pass args to the block?  My solution for the `yield` matcher will only work when there's not another one like this.
* I'm really not happy with how the logic for this is factored.  Having one method named `perform_block_matches_while_only_calling_block_once` and then another named `perform_block_matches_while_only_calling_block_once_against` is terrible, but it was the best I could think of.  Suggestions?
* This changes the semantics of `or` in a subtle way: before, we would not run `matcher_2.matches?` if `matcher_1.matches?` was already true as it's not necessary to check the second.  For block matchers, we check both up front because we only want the block to get run once.
* I don't think we have any matchers like this but a custom matcher could theoretically call a block multiple times which could make things odd in these situations (particularly if it was the outer matcher -- then it would cause the inner match to be performed multiple times).  Should we do anything about this?

TODO:
- [x] The coverage for the `or` case isn't as fleshed out as the `and` case -- flesh it out.
- [x] Provide clear errors for the cases we won't support (such as two `raise_error` matchers).
- [x] For whatever additions to the protocol we make, document them.
- [x] Get the build green :).
Good question.  I see the as roughly equivalent, with slightly different perf characteristics depending on if the method being defined is the rare case or common case.  If it's rare that the method is defined, I suspect a `respond_to?` check would be worthwhile since exceptions are expensive, but if the method is usually defined, then the `respond_to?` check is normally a wasted check and confidently calling it with a rescue would be more performant.

I used the `rescue` pattern here:

https://github.com/rspec/rspec-expectations/blob/2b79cc3cb0c0863452101d0a951483eca8b7d70f/lib/rspec/expectations/expectation_target.rb#L106-L110

...but all built-in matchers (and those defined by the custom matcher DSL) define `supports_block_expectations?`.  I hadn't done the same here for `expects_call_stack_jump?`, but I think I should, and then it'll make sense to keep the rescue approach.