Taking j as i32 was a weird choice (only for the -1), and technically
caused issues for invocations with more than u16::MAX tweaks (not that
people might use that many tweaks, but just in case...)

I like the way with chunks_exact more, as we get the remainder for free
and we don't have to do the chunk.len() dance

makes little sense to be no_std if the dependencies use std

We should test there, but for convenience, the tests currently rely on
std being there (mostly because of Vec allocations, also transitively
via hex).

Since the actual code doesn't change between std and no_std, I guess
we're fine for now with not testing the no_std version.

The trick is to use an intermediate enum which can either contain a
slice (the local tau block/nonce) or the passed in AsRef. This way, we
unify the two types.

turns out, we're not using much of it anyway

It turns out that we only really iterate over those items once, in
aez_hash. We're perfectly fine just accepting an iterator, and to make
it even more generic, we use AsRef to not limit ourselves to byte
slices.

Most of this commit is just changing the function signatures of all
functions that pass a Tweak downstream.

In the next step, we could update the Aez::encrypt function to take
generic arguments. That could for example allow to pass a slice of
slices, or a vec of vecs. However, simply changing to generics is
unergonomic, as callers might have to specify generic arguments. That
sucks, so we need to figure out something else first.

there are no vectorized instructions in this code