This commit was made by reverting the previous commit, then
re-running the script I used to generate it.  In theory there should
be no semantic changes: only changes due to improved formatting from
cargo edit.

I followed the following procedure to make these changes:

* I used maint/changed_crates to find out which crates had changed
  since 0.3.0.
* I used grep and maint/list_crates to sort those crates in
  topological (dependency) order.
* I looked through semver_status to find which crates were listed as
  having semver-relevant changes (new APIs and breaking changes).
* I scanned through the git logs of the crates with no
  semver-relevant changes listed to confirm that, indeed, they had
  no changes.  For those crates, I incremented their patch-level
  version _without_ changing the version that other crates depend on.
* I scanned through the git logs of the crates with no
  semver-relevant changes listed to confirm that, indeed, they had
  no obvious breaking changes.
* I treated all crates that depend on `arti` and/or `arti-client` as
  having breaking changes.
* I identified crates that depend on crates that have changed, even
  if they have not changed themselves, and identified them as having
  a non-breaking change.
* For all of the crates, I used `cargo set-version -p $CRATE --bump
  $STATUS` (where `STATUS` is `patch` or `minor`) to update the
  versions, and the depended-upon versions.

These crates had only clippy fixes that do not affect their
behavior:
        tor-bytes
        tor-cell
        tor-events
        tor-linkspec
        tor-netdir
        tor-socksproto

This crate only had the cargo-husky dependency removed, which
does not affect compatibility:
        tor-llcrypto

Since these changes have no compatibility effects, it is not
necessary to bump the versions of these crates which other crates
depend on.

Add a few coverage-driven tests

See merge request tpo/core/arti!536

add link to coverage reports

Closes #251

See merge request tpo/core/arti!537

Standardise shell

Closes #425

See merge request tpo/core/arti!533

Break TorClientConfig out of ArtiConfig and warn on unknown config keys

Closes #459 and #417

See merge request tpo/core/arti!529

We can have mem::take, hooray.

As per
  tpo/core/arti!529 (comment 2807331)

This was a slip.

As per
  tpo/core/arti!529 (comment 2807330)

Also, if we get an IoError from a call to fs-mistrust, report it as
an IoError.

ci: don't disable arti permission checks, fix resulting issues

See merge request tpo/core/arti!530

This makes the function a tiny bit clearer.

This is not a doc comment because we don't want it to be public: it
must refer to private fields, etc.

Not available in our MSRV.

I think this is a leftover from a previous version of this expression.

As per
  tpo/core/arti!529 (comment 2807070)