Fix the moves fuzz target.

[cfallin]

Two fixes uncovered by a warning noted in #96:

• The iteration that was meant to be adding between 0 and 2 scratch registers was adding zero or one instead, because it was written as for i in u.int_in_range(0..=2) rather than for i in 0..u.int_in_range(0..=2)?. This is somewhat subtle but the Result is iterable so it was choosing zero if u's input ended (making it unable to provide an arbitrary int) or one otherwise. This still would give some interesting fuzz coverage but was clearly not the original code's intent.

• Separately, it seems this fuzz target hadn't been run comprehensively in a while (we just run the toplevel ion_checker target on OSS-Fuzz, which checks the whole allocator; this target is meant to be a more focused way of testing the move resolver when hacking on it, and probably isn't worth the OSS-Fuzz time otherwise). It pretty quickly hit a panic in the fuzz target itself on a stack-to-stack move, because earlier it was written not to generate these; but now it does, and we handle them successfully in the move resolver, so there's no reason to panic about a bad testcase.

[elliottt]

Looks great! Thank you for the write-up!