We want to launch phase 1, wait for it to bootstrap, then launch
phase 2, then etc.

These configurations seem to require the network to bootstrap for a
bit before we have a working setup for the single onion services to
publish.  This is what our multi-phase code is for.

Chutney supports multiple phases so that we can configure the
network in a particular sequence.  But to use them in a shell
script, we'll need to have some way to ask chutney how many phases a
network has.

There were no bash-specific features in this file, so eliminate
dependency on bash and use regular sh. Shellcheck tests pass with
the #!/bin/sh shebang.

For #33604

This network is not only useful, but it's an example of multi-phase
initialization.

When we fix #34446 in Tor, we will need to have at least three
AssumeReachable relays on every network, or else Tor relays won't
ever actually upload enough descriptors to build circuits, and so
they won't upload their descriptors, and so on forever.

Out of the 68 files in the torrc_templates directory, only 32 are used
by Tor or Chutney for testing.  I'm removing the extraneous ones in
order to reduce our maintenance burden.

We can restore any of these that I was wrong about.

Out of the 66 networks in the networks directory, only 13 are used
by Tor or Chutney for testing.  I'm removing most of extraneous ones
in order to reduce our maintenance burden.

I'm keeping these on request from dgoulet:
   basic
   hs-ob-v3
   hs-v3
   hs-v3-ipv6

We can restore any of these that I was wrong about.

There's some kind of timing bug in Tor 0.3.5, where it fails
verification immediately after bootstrapping. Add a wait time to work
around this bug.

Replaces the previous 0.3.5 minimum bootstrap time, which fails for the
ipv6-exit-min network.

Now we're checking microdescriptors, the 0.3.5 timing bug can't be due
to descriptor propagation. So there must be some other subtle timing
bug.

Fortunately, this bug is fixed in 0.4.0 and later.

Chutney doesn't check for bridge descriptors or onion service
descriptors, so we need to wait for extra time in bridge and
onion service networks.

Tolerate being called early during bootstrap, and being called on old
tor versions without ed25519.

And explain that we're waiting for bridges

Analysis tools such as vulture treat functions configure, restart, and
wait_for_bootstrap in Network as unused, when in reality they are called
from the ./chutney commandline. Make this explicitly clear.