Factor out moving over loci to an iterator to allow for folds

I wanted to factor out moving over loci for a set of SlidingWindows.  Until now we had only performed a flatMap over loci in a window collecting results at each loci.  I wanted to do two things 1) Factor out the code to move loci by loci over a set of sliding windows and 2) Add some other operations as we move loci by loci, i.e. a fold so we can aggregate data about the reads in order.  I will add some tests for the fold, but wanted to get some feedback earlier on.

cc @timodonnell Might be worth checking out for you if you are looking to get back into guac things.
"Iterator always returns the same Seq[SlidingWindow[Region]], but with each SlidingWindow[Region] having been mutated to advance it"

Yes that is correct.  This is a an iterator over `N-Tuple [ Seq[Read] ]` where N is the number of samples, and the seq of reads are those that overlap the locus for each sample.  However, `SlidingWindow` stores `newRegions` as well which tell what we recently added for pileup creation.

"as it currently stands is that it would be possible for consumers of this iterator to advance any of the windows on their own, outside of the control of this iterator"

Yes they could I think I addressed this by making setCurrentLocus private to the package, but it still felt funny to me and I'm sure there are other cases where it can be affected.  The public aspects are `currrentRegions` and `newRegions` which being mutated would not affect the iterator.

Another way to look at this would be SlidingWindow was an Iterator[Seq[Read] and then this was simply two SlidingWindow's zipped.