Compute next argument on declaration

[BenWoodworth]

Resolves #12

Now parameter arguments are no longer iterated between parameterize iterations, and always occur during, when the parameter is re-declared.

This change makes argument iterator next calls consistent between the first declaration (which calls next during the parameterize iteration), and all subsequent calls (which, before this commit, would occur between parameterize iterations). This makes debugging argument issues more intuitive, enables performance profiling to highlight specific parameter properties if argument computation is slow, and lets exception call stacks trace through the call site with relevant stack frame context. None of this is possible when argument iteration is queued up and done separately behind the scenes outside of parameterize iterations.

This change also makes the implementation easier because the arguments don't actually have to be queued up to be iterated. The logic that moves the parameters to the next argument combination was removed, instead storing the last parameter with more arguments, so that it can be changed to the next argument during the following parameterize iteration. This also means that the parameterize while loop condition can be factored out and checked without side effects, in addition to the break early logic. So, now startNextIteration contains all the state-changing code, and simply sets a few variables.

This is a backwards-compatible change, since all code should still behave the same. Since parameters are still iterated in the same order (now it's just during the iteration), dependence between parameters isn't an issue. Since parameter iterators shouldn't have side effects, the fact argument iterating is spaced out (through a parameterize iteration) shouldn't make a difference. Argument iterators with side effects could have changed behavior, e.g. if an argument iterator modifies global state, it previously happened before the block was invoked, but now would happen during, potentially after a statement that depends on it. However, argument iterators with side effects are specifically unsupported according to the parameter(lazyArguments) documentation, so this isn't an issue.