Previously the user had to hit the / (/verify) endpoint repeatedly if
they wanted jmp-verifier to try delivering the code to the destination
number again (including if they wanted to advance from SMS to call
based verification).  Now jmp-verifier sets up its own timers and does
this automatically, as configured with $call1_timeout, $call2_timeout.

In particular, jmp-verifier will immediately send an SMS when /verify
is first hit.  After that, it will place calls to the number after
$call1_timeout and $call1_timeout + $call2_timeout seconds if the
recipient has not successfully verified their code by either of those
points.  Note that subsequent requests to /verify for the same number
within $code_ttl seconds of the first request will receive an error.
The user can try again after $code_ttl seconds have passed.

Excitingly, this change simplifies the code a decent amount.  Of
particular note is the removal of the jvr_hits-* keys, which are no
longer needed since we implicitly keep track of the number of times
the number has been contacted through the SortedSet of calls.  If the
number is successfully verified, then we just delete the remaining
calls we would have made.

So now jmp-verifier only uses a single "table", jvr_code-* - this
stores the code for the given number/user, just as it did before.  But
now we don't need any other keys due to the way calls are handled.

Note that the calls are now initiated by a timer, which fires every
600 milliseconds (0.6 seconds).  This is done as a way of limiting the
rate of our calls, since Plivo only allows a maximum of 2 calls per
second from a given account.  Since we only place at most one call per
firing of the timer, we'll never hit Plivo's limit.  This does make
the code a bit less efficient than it might be (since we're waking up
the CPU every 600 milliseconds to see if there's a call to process,
even if we know/could have known that there aren't any).  But it does
also make the code extremely easy to follow, and in practice it seems
that this strategy uses very minimal CPU resources so not a big deal.