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 :).
`RaiseError` was an outlier at 118 lines, and the need to add the definition of `expects_call_stack_jump?` was going to force me to bump it up even higher.  As you can see in c5c5d36e1bd7a60a70c832e7010c31249e8d4bf9, the next highest is 90 (my changes to `Compound` later forced me to bump this up to 96).  I think that having the rubocop setting based on the one outlier is not very useful (since we really don't want classes getting near that long).  While it would be good to refactor `RaiseError` at some point, my bent is generally to only refactor in two situations:

* When I've first created a class (as part of red-green-refactor).
* When the refactoring will make a bug fix or new feature that I want to work on next easy to implement.

When neither of these is true, the poorly factored code is still a code smell and an eye sore but there's little benefit to the refactoring and a lot of risk, so I tend to leave as-is.  I think `RaiseError` is in this category right now: as bad as the code is, it works fine and there are no known bugs or new features planned for it, so I don't think refactoring it makes sense right now.

Given that, whitelisting it (so that we can have a more reasonable class length setting) seemed like the prudent thing to do.