I think we shouldn't be moving fuzz. We might move queue, list, and stack, but that probably
requires cleaning up the API beforehand.

The meta pattern with stdx is separating "neatly organizable" stuff from inherently somewhat messy
things. If a datastructure has a really cleary API, it might go to stdx. If we are unsure about the
design, it's better to keep in VSR, to keep the bar for stdx higher. This is useful because of the
reverse pressure: when adding stuff to stdx we put extra effort to make sure the API is just right.

With fuzz, things like fuzz.FuzzArgs or fuzz.FuzzArgs are cleary zig build fuzz specific, and
shouldn't be part of stdx. random_int_exponential is interesting! I considered making it just a
method of prng, but decided against it, because it uses floats inside, and we'd preferto avoid
floats if possible. So that's why PRNG in stdx forbids usage of floats, and the function lives
in fuzz.zig --- the latter is not part of stdx and can be more relaxed. In other words, if random_int_exponential is in stdx, it should be method of PRNG.

queue.zig, list.zig, and stack.zig look like stdx candidiates, but we need to solve verify problem
by making the caller pass .verify = constants.verify, explicitly to init. We should also figure
out what to do with name. As it stands, the name is a busywork which we needlessy do, we don't
actually us it anywhere! I haven't verifyied it, but I think what we should do is, instead of
name, pass and verify the capacity upper bound (which might be unbounded), like we do in stack.
The idea behind name is to track unbounded queues, but I think many queues can actually be
bounded? Not sure if that's right, but the .name does feel to add-hoc for stdx (but fine for VSR).