Loop unrolling

This definitely needs some more test cases before merging, but I wanted to get feedback on this proof of concept `mark_for_unroll` logic.  The ASP way for loop unrolling was the do a visitor that deepcopied the body of the loop `unroll_factor` amount of times.  This meant that any subsequent operations (transforms, validators) meant traversing this new huge tree.  The logic presented here will hold off on unrolling the loop until necessary (for now at codegen, would this be necessary for dotgen?)  It should save a lot of time if there are still transformations/other passes that need to be done over the body of the for loop.

One downside is tree does not represent what it actually is until codegen stage.  I can't really see running into any issues with this.  Seeing as the idea of unrolling is that it shouldn't logically change the code, a specializer writer really shouldn't be touching unrolling until the logic of the specializer has been written and correctness verified.  At that point, tuning with unrolling won't change any of the logic, and thus will not require any tree inspection.

Thoughts?