Add zip_eq adapter to IndexedParallelIterator (ZipEq struct version)

[chrisvittal]

This replaces #389, and is much the same. Re-implemented zip_eq using a ZipEq struct that is a wrapper around Zip to better align zip_eq with the adapters present in rayon, itertools, and the standard library.

Closes #386, as I believe it has been decided to not implement zip_longest.

@cuviper it was unclear from your comments where you wanted additional documentation. Please advise and I will update.

[cuviper]

it was unclear from your comments where you wanted additional documentation.

On struct ZipEq, since this is public. Doesn't need to be a lot, just something relating it back to the zip_eq method.

[chrisvittal]

I've been attempting to diagnose CI failures on nightly, and it appears that compiletest_rs is broken on current nightly (rustc 1.20.0-nightly (3bfc18a96 2017-06-29)) on mac and linux. I will investigate more when I get the chance.

The nightly before today works fine.

[cuviper]

It seems compiletest_rs 0.2.8 fixed that issue. I restarted your nightly CI runs, and Linux passed, but macOS is still queued...

[chrisvittal]

In the demo, there are dependencies on both cocoa-0.3.3 and cocoa-0.5.2, which both fail to build on current nightly. It seems that servo/cocoa-rs#166 fixed this for the current cocoa-rs (0.9.2), but I'm not sure what we can do here.

[cuviper]

Well that's awkward. I wonder what caused the change in Sized behavior -- @nikomatsakis ?

Our dependency tree looks something like this:

• rayon-demo
  • glium
    • glutin
      • cocoa 0.3
      • winit
        • cocoa 0.5

Perhaps we should just skip rayon-demo for CI on macOS. We'll still have the basic rayon tests, but we don't need to get in the business of troubleshooting graphics stacks here...

[bluss]

I think that this is better than zip_eq in itertools, because this is checking up front and then iterating unhindered.

itertools' zip_eq is lazy (only can panic if it reaches an end) and consequently gets in the way of good loop optimizations since it's putting a panic check between each iterator element.

If itertools changes it might be to change zip_eq to apply in just the cases where we can check iterator length up front (a passing thought, it might then exclude exactly those cases, like when filtering, where the check is most crucial.. hmm).

[cuviper]

Can you please rebase this to see how CI fares now?

[cuviper]

Thanks!