This will allow us to keep the code DRY by extracting a method with the
identical bits

Array will return a single-element array in case the arg is a single value, or a
Hash converted to an array in case the arg is a Hash. We then yield the single
element or the key value pair, and return the result of the last yield

Mock#{expects,stubs} already handle methods_vs_return_values/method_name_or_hash
Note that this change isn't 100% behavior preserving due to the separation of
Mockery#stub_method call from the Mock#{expects,stubs} call. It's possible that
midway through argument iteration, stub_method raises a StubbingError, which
would leave some methods stubbed without having an expectation set for them. However, I think that's still OK, since you wouldn't expect anything useful to happen after a StubbingError anyway. We're changing undocumented/unpublished behavior in a way that shouldn't matter.

Keep the stubba_ prefix to avoid accidental name clash with other valid methods

When calling expects/stubs with a hash (method_names_vs_return_values),
only the last expectation would get returned. Any further 'expectation
setting' methods chained to that call would, therefore, get called only
on the last expectation. This seems arbitrary, and neither evident nor
intuitive. We now 'extract' the expectation setting methods into a
_virtual_ interface, 'implemented' by both Expectation and
ExpectationSetting, and return ExpectationSetting instead of Expectation
from the expects/stubs methods. This allows us to pass any further
expectation setting method calls on to _each_ of the multiple
expectations, rather than just the _last_ (or some other arbitrary)
single expectation.

Mock wasn't the right place for calling it. The new yield mechanism is
more general and less ugly, and allocates responsibilities more
appropriately.

Closes freerange#468 and sets us up to reduce the surface area of the internal
API exposed to users, by inlining anticipates into expects and using
that from stubs

This reduces the surface area of the internal API exposed to users as
suggested in freerange#467

Given that the public API of Expectation consists solely of expectation
setting methods, and that the matching, verifying and other misc methods
aren't part of the public API, it makes sense to equate the Expectation
protocol implicitly to the ExpectationSetting protocol. If we were to
segregate interfaces, we might wanna have other internal-facing
interfaces like ExpectationMatching, etc.

By naming this CompositeExpectation, we don't need (as much) to expose
it or to include it in/update the documentation because as far as
clients are concerned, they still get back an Expectation (technically,
something that quacks like an Expectation).