This doesn't actually do the right thing: it will make somebody get
ignored completely for a release if they _only_ use their
alternative name.

Disclaimer: I have no idea what I'm doing when it comes to shell
scripts.

maint/thanks.sh autogenerates a list of contributors since a revision
(that you pass it on the command line), intended to make the work of
going through the shortlog a bit less manual. It can exclude
contributors' names given in maint/exclude_contributors.txt, in order to
filter out people who work for Tor, or who commit under more than one
name.

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?