Rust implementation of onion service client puzzles (Proposal 327)

It's a whole big stack of Rust to implement Proposal 327 proof-of-work client puzzles.

For #889 (closed)

The topmost module here is a sketch of basic functionality for the v1 solve/verify protocol itself, without any of the higher level pieces or any opinion about wire encoding. It has passing unit tests which use the test vectors I generated for C-tor. I've tried to sketch out one way we might handle error propagation at this level, but this part feels the most vague to me. Otherwise, I've mostly just tried to design an API that's easy to use and high performance.

I've left out the connection to any event loop or thread pool here, but there's some commentary about how that might go.

Under that top module are two fairly complete crates I've written as new Rust implementations of tevador's Equi-X and HashX algorithms. It's a lot of code, but I've tried to make it all as unsurprising and idiomatic as I can. There is some unsafe code in each of these modules, in Equi-X for memory management and in HashX for dynamic code generation. I've run what I can using miri and it's all sound according to my understanding of Rust, x86_64, and aarch64, but please feel free to scrutinize those bits heavily.

Both algorithm crates have benchmarks too. I haven't looked closely at performance yet, just enough to know that nothing is obviously broken and we're in the same ballpark as the original implementation.