This version makes all locks per-handle rather than per-process, by
moving from lockf() to flock() on unix.

This switches out `arti`'s argument-parsing library with `clap`, which
is a lot more featureful (and very widely used within the Rust
ecosystem). We also now use a lot of `clap`'s features to improve the
CLI experience:

- The CLI now expects a subcommand (currently, either "help", or "proxy"
  for the existing SOCKS proxy behaviour). This should let us add
  additional non-SOCKS-proxy features to arti in future.
- `clap` supports default values determined at runtime, so the way the
  default config file is loaded was changed: now, we determine the
  OS-specific path for said file before invoking `clap`, so the help
  command can show it properly.
  - The behaviour of `tor_config` was also changed; now, one simply
    specifies a list of configuration files to load, together with
    whether they're required.
  - That function also way overused generics; this has been fixed.
- Instead of using the ARTI_LOG environment variable to configure
  logging, one now uses the `-l, --log-level` CLI option.
  (The intent is for this option to be more discoverable by users.)
- The `proxy` subcommand allows the user to override the SOCKS port used
  on the CLI without editing the config file.

The Futureproof<T> type lets you serialize and deserialize types whose
representations might change (most useful for enums that might grow
additional variants). It uses #[serde(untagged)] to accomplish this.

This gets used in order to make the `disabled` field of `Guard` more
robust against future guard disablement reasons being added.

A test was also added to verify correct behaviour of the new type.

As per arti#175, we'd like to be able to handle newer Arti versions
storing additional state in the persisted state files, without dropping
this data on the floor when we write out changes to these files.

Use the #[serde(flatten)] mechanism to achieve this, by adding catch-all
HashMap<String, JsonValue> fields to all structs that are at risk of
this happening to them.

These are my fault; I merged the wrong version of !102. :p

There seems to be some issue here with the new WaitFor code,
where using the same MockSleepProvider with both of these wait_for()
calls gives questionable behavior under some circumstances (like
when running under Tarpaulin with the wrong set of flags).

I'm not sure what I was thinking here.

We must not apply our new path-bias behavior (where we blame a guard
if it gives us too many indeterminate circuit failures) if the path
was not chosen at random.  If too many random paths fail, we know
that's suspicious, since the other relays are a random sample.  But
if a bunch of user-provided paths fail, that could simply be because
the user's chosen exit is down.

We now track, for every guard: the total number of successful
circuits we've built through it, along with the total number of
"indeterminate" circuits.

Recall that a circuit's status is "indeterminate" if it has failed
for a reason that _might_ be the guard's fault, or might not be the
guard's fault.  For example, if extending to the second hop of the
circuit fails, we have no way to know whether the guard deliberately
refused to connect there, or whether the second hop is just offline.

But we don't want to forgive all indeterminate circuit failures: if
we did, then a malicious guard could simply reject any second hops
that it didn't like, thereby filtering the client into a chosen
set of circuits.

As a stopgap solution, this patch now makes guards become
permanently disabled if the fraction of their circuit failures
becomes too high.

See also general-purpose path bias selection (arti#65), and Mike's
idea for changing the guard reachability definition (torspec#67).
This patch doesn't do either of those.

Closes #185.

Instead of racily advancing time forward, this commit attempts to rework
how WaitFor works, such that it makes advances when all sleeper futures
that have been created have been polled (by handing the MockSleepRuntime
a Waker with which to wake up the WaitFor).

The above described mechanics work well enough for the double timeout
test, but fail in the presence of code that spawns asynchronous /
background tasks that must make progress before time is advanced for the
test to work properly. In order to deal with these cases, a set of APIs
are introduced in order to block time from being advanced until some
code has run, and a carveout added in order to permit small advances in
time where required.

(In some cases, code needed to be hacked up a bit in order to be made
properly testable using these APIs; the `MockablePlan` trait included in
here is somewhat unfortunate.)

This should fix arti#149.

We need this now that we check for contributory behavior.

Now that we have two kinds of isolation tokens (those set on a
stream, and those set by the stream's associated TorClient), we
need a more sophisticated kind of isolation.

This fixes the bug introduced with the previous commit, where
per-stream tokens would override per-TorClient tokens.

When two TorClients are isolated, their streams shouldn't share
circuits, even though they share internal circuit and guard state.

Closes #202.

(This appears to be the emerging consensus of how to handle
RUSTSEC-2020-0159.)

(This appears to be the emerging consensus of how to handle
RUSTSEC-2020-0159.)

Solves a name conflict with the existing tor_client create.

Closes #130.