Dependencies cleanup

[lqd]

This PR cleans up the dependencies, to reduce compile times on a clean build:

• removes unused or barely used dependencies (failure, assert_cli, env_logger): we don't have so many errors or logging for them to be worthwhile yet.
• switches from clap / structopt to pico-args to avoid compiling proc_macro parsing code
• just in case, ensures we're using datafrog-2.0.1 as version 2.0.0 triggers the rustdoc ICE Rustdoc ICEs when a dependency has duplicate generic bounds to functions returning tuples rust#57180

While CLI arguments handling becomes less automated and slightly more verbose, this all reduces compile times greatly: a cargo build --release clean build (on a beefy machine) goes from 52s to 17s (as the number of dependencies goes from 60 to 12).

The dev-dependencies haven't changed much, maybe 30 crates less than before and 20s faster, but I'll see what I can do with these later.

[lqd]

And just because I wanted to play with cargo's new -Z timings, here's how the build timings look for this PR (on an old laptop and in debug mode, so the durations are different from the PR description — still a 3x difference):

• before the PR — cargo build: 111s, build timings
• with the PR — cargo build: 39s, build timings

This makes me want to check whether we require the default-features of petgraph which also themselves require dependencies (even though, we could easily remove it completely if we wanted to: we already did graph reduction in a way similar to what is needed by the --dump-liveness-graph feature, in the CFG compression PR).

[amandasystems]

This makes me want to check whether we require the default-features of petgraph which also themselves require dependencies (even though, we could easily remove it completely if we wanted to: we already did graph reduction in a way similar to what is needed by the --dump-liveness-graph feature, in the CFG compression PR).

I think it makes total sense to have a centralised graph-compression implementation, because as you point out it is definitely the same logic. I also think it makes sense to drop --dump-liveness-graph, as it was something I used when working with the liveness implementation, and I suspect it's done now.

The way I dreamed this up is that the compression algorithm would just be a BFS that takes a function acting as a "are these two equal" predicate for each prospective pair of nodes to merge. That way the logic of determining the equality classes of nodes can be abstracted out and re-used whenever we need a graph compression over anything.