For now, this avoids having to separately handle
AuthorityBuilderError, DirMgrConfigBuilderError, DownloadScheduleConfigBuilderError,
NetworkConfigBuilderError and FallbackDirBuilderError when anyhow is not
used.

Turn off a clippy warning.

Suggested by @cheako.

The default soft limit is typically enough for process usage on most
Unixes, but OSX has a pretty low default (256), which you can run
into easily under heavy usage.

With this patch, we're going to aim for as much as 16384, if we're
allowed.

Fixes part of #188.

I don't love this approach, but those errors aren't distinguished by
ErrorKind, so we have to use libc or winapi, apparently.  At least
nothing here is unsafe.

Addresses part of #188.

Previously we would sometimes fail to report that we had
successfully bootstrapped.

(Previously we'd report it as successful even if the inner download
task was a failure.)

The previous code would report all failures to build a circuit as
failures of the guard.  But of course that's not right:  If we
fail to extend to the second or third hop, that might or might not
be the guard's fault.

Now we use the "pending status" feature of the GuardMonitor type so
that an early failure is attributed to the guard, but a later
failure is attributed as "Indeterminate".  Only a complete circuit
is called a success.  We use a new "GuardStatusHandle" type here so
that we can report the status early if there is a timeout.

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.