[WIP] 64-bit counters for legacy and XChaCha variants, fix looping counter regressions

[jpdoyle]

This is still WIP. So far it is basically a PoC of what is needed to perform these changes. The overall checklist before merging is:

• [x] Restore the deleted regression tests
• [x] Correct handling of the full 256GB key stream in Ietf ChaCha20
• [x] Correct handling of 64-bit counters in legacy and xchacha variants
• [x] ChaCha20 software backend cipher-mode support
• [x] ChaCha20 SSE2 backend cipher-mode support
• [ ] ChaCha20 AVX2 support
• [ ] ChaCha20 NEON support
• [ ] Salsa20 software backend support
• [ ] Salsa20 SSE2 backend support
• [ ] Salsa20 AVX2 backend support
• [ ] Salsa20 NEON backend support
• [ ] Update traits so that there is an explicit representation of a looped/saturated counter. Currently the implementation of StreamCipherCoreWrapper does not allow me to directly implement a cipher that stops once it would loop; in the current implementation I get around this by effectively using a 64-bit counter for the 32-bit counter mode, which allows me to distinguish between a just-initialized cipher (block_pos = 0, pos = 64) and a looped cipher (block_pos = 2**32, pos = 64). Note that this does not currently allow correct behavior at the end of a 64-bit-counter keystream.
• [ ] Convert the Ietf variant to use a 32-bit counter again, fixing the bad_overflow_check{6,7} seek-focused tests
• [ ] Update the arithmetic in SeekNum::from_block_byte in traits to match the looped counter representation, thereby fixing https://github.com/RustCrypto/traits/issues/1808. (NOTE: the test in that issue is present in this PR, and succeeds; that is because I use a 64-bit overall counter even in 32-bit Ietf mode)

This would close https://github.com/RustCrypto/stream-ciphers/issues/334, https://github.com/RustCrypto/stream-ciphers/issues/391.