add workspace_hack crate

Our builds can be a little inconsistent, because Cargo doesn't deal well
with workspaces where there are multiple crates which have different
dependencies that select different features. As a workaround, copy what
other big rust projects do: add a workspace_hack crate.

This crate just pins down a set of dependencies and features that
satisfies all of the workspace crates.

The benefits are:
- running `cargo build` from one of the workspace subdirectories now
  works without rebuilding anything.
- running `cargo install` works (without rebuilding anything).
- making small dependency changes is much less likely to trigger large
  dependency rebuilds.

workspace_hack/src/lib.rs

@@ -0,0 +1,23 @@
+//! 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.