hex-literal instead of blobby?

In https://github.com/RustCrypto/stream-ciphers/pull/244 and https://github.com/RustCrypto/stream-ciphers/pull/245 we encountered the problem of the blobby test vectors being opaque. As serendipity would have it two people opened PRs because they thought test vectors were missing.

It appears they were, but it's presently difficult to ascertain that because all of the test vectors are in an opaque binary blob. I ended up having to write a small tool to dump the test vectors as hex so I could compare them to the ones in the RFC.

If the goal of blobby is to reduce the size of the test vectors in a compiled binary, it seems like hex-literal accomplishes that by encoding the test vectors as binary at compile time.

If the goal is to reduce the size of the crate, I really doubt it's accomplishing much over gzipped hex. But in the process, we also lose comments about the progeny of test vectors, which makes it difficult to answer questions like what ones we have included for each crate (see aforementioned PRs).

I would suggest that each of the crates in traits defines a test vector struct, and we populate an array of those using hex-literal.

Separately I think it'd be great to have a test-vectors crate feature for each of the algorithms that would allow such vectors to be used as part of an initialization self-test (which is a common thing for e.g. FIPS).

Review the test-vector handling in the crates under traits and the linked stream-ciphers PRs, focusing on how blobby currently represents vectors. Compare that approach with hex-literal and determine the scope of defining per-crate test-vector structs and arrays. Done should make vectors readable and traceable to their sources; the separate test-vectors feature would need its own design.