Teach "lock" facility to replay the last request.

Instead of simply dropping all requests that arrive while locked,
we keep a record of the most recent such request, and then reissue
it when the lock becomes available.

This is the desired behavior when using "lock" around "search",
to avoid bug #54 -- if further user input arrives while the lock
is taken by one call to the search callback, we don't want to
start another simultaneous call to the search callback, but when
the first call completes we do want to act on the further user
input to avoid leaving the user with a stale UI.

I changed the "lock" facility to always act as described here,
because it's only used in one place and this behavior is appropriate
there; if we want to keep the "lock" facility more general we could
make this behavior optional via a "queueAndReplayOne" flag to lock.

Fixes #54.
Merge pull request #56 from metamatt/mg-fix-54

[Fix #54] Teach "lock" facility to replay the last request.