Reduce crates in Hipcheck workspace

[alilleybrinker]

Currently, Hipcheck is organized into a workspace with a lot of crates. This decision was made at a historic point before incremental compilation in Rust had landed, and so the crate (a single library or binary) was the unit of compilation, and splitting into smaller crates meant faster compile times. Today, Rust has incremental compilation, and the drawbacks of the "many crates" approach to the workspace outweigh the benefits.

Some key insights:

Publishing Hipcheck

We'd like to be able to publish Hipcheck to crates.io, but doing so would require publishing its dependencies, and there are a lot of dependencies.

Removing the Library / Binary Split

It had previously been under consideration to expose both a Hipcheck library and binary interface, even if provided by separate crates, so users of Hipcheck could use it as a library within other tools / systems. At this point, that doesn't seem especially useful, and also means the Hipcheck library API is external and needs to commit to some level of stability to support outside consumers. I don't think we really want that to be the case, so the goal is to remove the Hipcheck library crate and instead focus solely on delivering Hipcheck as a binary, and on the stability and guarantees of that binary interface.

Making Hipcheck Easier to Contribute To

Right now the crate structure of Hipcheck is pretty complicated. There are a lot of parts, and they are interdependent. This isn't intractable, but it does raise the barrier to entry for people who may consider contributing to Hipcheck. With fewer crates, new potential contributors have less "cruft" of crate definitions to sift through, and more spatial locality for implementation info. I also think the IDE experience for working in a single crate is generally better than the experience for multiple crates.

Driving Down Build Times

Hipcheck is slow to build. This is in part at least an endemic problem for Rust, but it's also something we'd like to fix. While there are obviously many things that we could do with the many-crate setup to improve things, I believe it's easier to track, manage, and address in the context of a single crate.

Simplifying Changelog Generation / Management

More crates, more version numbers (even if incremented together), more changelogs. One crate, one version number, one changelog is a lot simpler.

---

The goal is to get Hipcheck down to a single binary crate called Hipcheck.