Now that nested matchers work, this passes without any special case
for arrays:

contains({foo: 'bar', baz: contains(12, 13)}).
	__matches({foo: 'bar', baz: [18, 12, 13, 15], stuff: this})

So now `td.matchers.contains()` can take a matcher for any (presumed to 
be) iterable actual argument, meaning td.matchers.contains(isA(Number)) 
would match actual arg `['a', 2]` or `{a: 'b', c: 2}`, but not `2` 
itself.

This commit also refactors any array specific logic out of the 
containsAllSpecified function, since once we're traversing a sparse
JS object, normal rules should apply that any specified properties be
matched appropriately.  

Finally, the commit flattens out the multi-return statements in each
instance.

In general, when I can remove a logical branch from a delegator unit
(this unit is said to be a "delegator" because its primary task is 
offloading work onto other units), I'll usually rework the naming to 
push the branch down. Therefore, "ensureDemonstration" became 
"popDemonstration", and instead of simply providing a null-check and a
potential error, it will now pop the CallLog itself and blow up as 
necessary.

Does it really matter whose job that is? No, not really. But is the 
resulting `verify` module cleaner? Absolutely! It no longer mixes levels
of abstraction quite so much (notice how before it was a little odd how
the unit had awareness of a repository object as well as 5 business 
logic modules)

This refactor is a good example of the kind of thought process that
discovery testing encourages which I typically would never have 
undergone had I just written the code (or even "classical TDD'd" it)

I expected this test to pass without changes, but it didn't!
To my surprise, destructured parameter assignment explodes
if the right side is null or undefined (this gives a good
error message in native v8, but when babelified the message
is not helpful).

Now, a decision: leave this gross `|| {}`, adding to the branching
complexity of the unit to mask over this language quibble, OR refactor
things around to push that complexity onto ensureDemonstration, so it
can effectively serve as the wrapper, throwing instead of returning a 
null or a default.

Note that in addition to verifying ensure throws (it will
actually use td's `log.fail` function), that it also asserts
this occurs prior to the other side-effect-having dependencies
so those are not called in this case.

This is not proper Kent Beckian triangulation, because 
I threw the if() statement in there before it was properly
required by the test. In practice I'll probably comment out
the branch with and without the tests to ensure it's being
demanded properly, which is hard to capture in a git log

This uses real Double, Call values and also the
actual CallLog. These are not application logic 
from the perspective of verify(), simply the place 
it gets its data from (as opposed to an argument, 
which is more typical).

Note the three test cases map to the three logical branches
present in the pseudocode comment, too. Everything is now
accounted for and everything from here on out is 
paint-by-number. If anything is hard AFTER this point, it's
because I'll have forgotten about how to satisfy a method
contract or decide I dislike something about the types being
passed around

This is just a handy way to guide remaining rewrite work

The code wasn't covered by any tests, which are pretty 
exhaustive for this feature. Hopefully it's actually dead
code, but if not hopefully someone finds it soon enough to
remember it was removed