Most of the structs in `arti-client` have example code now, to give a
clearer idea of how they're used.

Annoyingly, a lot of the types exposed in `arti-client` are actually
re-exports, which makes documentation a bit harder: example code that
references other parts of `arti-client` can't actually be run as a
doctest, since the crate it's in is a dependency of `arti-client`.

We might be able to fix this in future by doing the documentation in
`arti-client` itself, but rustdoc seems to have some weird behaviours
there that need to be investigated first (for example, it seems to merge
the re-export and original documentation, and also put the re-export
documentation on the `impl` block for some reason).

For now, though, this commit just writes the docs from the point of view
of an `arti-client` consumer, removing notes specific to the crate in
which they're defined. It's not ideal, but at least the end user
experience is decent.

Instead of putting a fully qualified name in the text, in most cases
we should just use the short name of the type or function we're
referring to.

In other words, instead of saying [`crate::module::Foo`], we should
typically say [`Foo`](crate::module::Foo).

I'm not 100% sure this is better, but it might help the user
understand how Arti works a bit better.

This overhauls the top-level `arti-client` documentation significantly:

- the "Using arti-client" section walks the user through all of the
  necessary steps to initiate a Torified TCP connection, and then
  provides a code example
  - this example is also available as `examples/readme.rs`; it's not run
    as a doctest, since it involves connecting to Tor
  - a "More advanced usage" subheading provides information about stream
    isolation (and can potentially be used for other interesting
    features once we get them).
- a new "Multiple runtime support" section was added to explain the
  purpose and usage of the `tor-rtcompat` crate
- the section on design and privacy considerations was removed; this is
  probably okay to keep in a README, but users of the crate aren't going
  to be interested in this (at least I don't think)

(also, the doc comment for `arti_client::Error` was fixed to make actual
sense)

This test uses a consensus that I've copied from
tor-netdoc/testdata.  I would include it directly, but I think that
will cause trouble when it comes time to run "cargo package".

This will let us test the state processing code without having to
give it up-to-date directory objects.

The previous version of this test used the old, racy version of
wait_for (see #149).  The new version is refactored so that
simulated time is only allowed to advance after each step is done,
so that we can actually be sure that each step in the process will
happen as it should.

In order to get the time-advances to proceed properly, and avoid
polluting state between tests, I've had to introduce some machinery
to encode the proper amount for time to advance.  It isn't something
I'd want to use for a whole bunch of tests, but for just one set,
it's fine.

These tests now pass reliably for me.

I wonder if a discrete-event-simulation approach (hello, Shadow)
would let us write tests like these to our hearts' content?

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.