use cargo-hakari to manage workspace_hack crate

workspace_hack is needed to avoid recompilation when different crates
inside the workspace depend on the same packages but with different
features being enabled. Problem occurs when you build crates separately
one by one. So this is irrelevant to our CI setup because there we build
all binaries at once, but it may be relevant for local development.

this also changes cargo's resolver version to 2

workspace_hack/src/lib.rs

@@ -1,23 +1 @@
-//! This crate contains no code.
-//!
-//! The workspace_hack crate exists only to pin down some dependencies,
-//! so that those dependencies always build with the same features,
-//! under a few different cases that can be problematic:
-//! - Running `cargo check` or `cargo build` from a crate sub-directory
-//!   instead of the workspace root.
-//! - Running `cargo install`, which can only be done per-crate
-//!
-//! The dependency lists in Cargo.toml were automatically generated by
-//! a tool called
-//! [Hakari](https://github.com/facebookincubator/cargo-guppy/tree/main/tools/hakari).
-//!
-//! Hakari doesn't have a CLI yet; in the meantime the example code in
-//! their `README` file is enough to regenerate the dependencies.
-//! Hakari's output was pasted into Cargo.toml, except for the
-//! following manual edits:
-//! - `winapi` dependency was removed. This is probably just due to the
-//!   fact that Hakari's target analysis is incomplete.
-//!
-//! There isn't any penalty to this data falling out of date; it just
-//! means that under the conditions above Cargo will rebuild more
-//! packages than strictly necessary.
+// This is a stub lib.rs.