There are some limitations here, as noted in the comments.

(When we're building a path with a guard, we need to tell the guard
manager whether the path succeeded, and we need to wait to hear
whether the guard is usable.)

The advantage here is that we no longer have to use a futures-aware
Mutex, or a blocking send operation, and therefore can simplify a
bunch of the GuardMgr APIs to no longer be async.  That'll avoid
having to propagate the asyncness up the stack.

The disadvantage is that unbounded channels are just that: nothing
in the channel prevents us from overfilling it.  Fortunately, the
process that consumes from the channel shouldn't block much, and
the channel only gets filled when we're planning a circuit path.

I tried using -Z minimal-versions to downgrade all first-level
dependencies to their oldest permitted versions, and found that we
were apparently depending on newer features of all three crates.

I'm kind of surprised there were only three.

By the time I merge this, most of the comments should have tickets
to go with them.

Also, refactor our message handling to be more like the tor_proto
reactors.  The previous code had a bug where, once the stream of
events was exhausted, we wouldn't actually get any more
notifications.

There are some missing parts here (like persistence and tests)
and some incorrect parts (I am 90% sure that the "exploratory
circuit" flag is bogus).  Also it is not integrated with the circuit
manager code.

This will let us provide a couple of better APIs for use in tor-guardmgr

The limitations with toml seemed to be reaching a head, and I wasn't
able to refactor the guardmgr code enough to actually have its state
be serializable as toml.  Json's limitations are much narrower.

I have no idea why this just turned up now.

ctrlc had rustsec issues, der was yanked

Closes #163