multiple levels of anon funcs: PAINFUL. Had to use
a captor to spec it, then b/c of how much setup
there was i ended up with two layers of beforeEach
to DRY it.

not happy rn

Decided to pull up the imperative stuff to the satisfy/index instead

* Stubbing now responsible for telling you its current outcome based
on how many calls it's gotten
* Stubbing now stores satisfying calls for easier traceability by 
td.explain (future proofing)

I could not for the life of me figure out why app code was being invoked
from a value object. Obviously it's a thing I (tell people to) avoid
doing, but as I dove in I realized that this stupid unit test was also
depending on this dummy implementation of satisfy() working in order
to also pass.

Not only was that unhelpful incidental coverage, it was obnoxious b/c
I needed to delete that implementation to start driving out an actual
satisfy() solution, and I didn't want to stare at this unrelated error.

Also it makes no sense why it's dangling on the matcher like that to
begin with. It's only needed in a couple places to make sure we're 
looking at a callback matcher before we invoke one.

I suspect we'll move to a mode where every single layer of an imitation
is mapped to a Double value, regardless of whether `fake` is a clone or
a test double function. it'll allow us to say quite a lot more when 
td.explain()'ing. 

However, that's not something we have to solve right away (pre-relaunch)

Key insight here was that the public API really shouldn't be the same
as the private API, because we want to encourage passing around Double
objects internally and only expose the fake externally. Additionally,
the imitation module is doing a lot of the heavy lifting now and this
isn't nearly as complicated as it was once going to be.

grammar tweak

Improve TS Support

Fix outline of FAQ in README