Basic interoperability between Java8 Streams and Scala collections.

[Ichoran]

This consists of
(1) toScala[Coll] extension methods for Java8 Streams
(2) seqStream and parStream extension methods for Scala collections
(3) A manually specialized set of Accumulators that let you quickly
save a stream for multiple re-use.
(a) accumulate and accumulatePrimitive methods on Java8 Streams
(b) to[Coll] on Accumulators
(c) .iterator, .toArray, .toList also

There is a lot of redundant code in the Accumulators since it is difficult
to pull out common functionality without endangering performance of the
manually specialized cases.

Tests written.

Scaladocs written for the new classes.

No top-level docs; feature is not complete.

[retronym]

@Ichoran You can fix the build failure with https://github.com/retronym/scala-java8-compat/tree/review/45

I'd prefer to add the *Accumulator classes to scala.compat.java8.collection for now, even if we intento to use scala.collection.java8 as the package name if/when we add them to the core library.

[Ichoran]

@retronym - I'll rebase to get the checks working. I put Accumulator in Collections in case it needed to get at the internals of various collections. I was planning to move it out only when I'm convinced I don't need to. But I can always do it the other way (have it out, and move it in if I need to).

[retronym]

@Ichoran thanks. If we do need collection internals, I'd prefer to end up with miminal shims in the collection package, as we did with scala.concurrent.java8.FutureConvertersImpl.

[Ichoran]

@retronym - I moved things around, but Travis seems very unhappy and I'm not entirely sure why. It says there are two errors, but there are zillions of lines that say both error and warning, and not all in code that I changed for this PR. How do you find anything in those giant logs anyway?

[retronym]

The complaints are from the Javadoc tool, which is running over synthetic Java sources generated from by the genjavadoc SBT/compiler plugin.

The [error] part means that you are reading something that was printed to stderr. It is unfortunate that Javadoc prints its warnings there, and that SBT's rendering doesn't distinguish stderr from log(Level.Error, ...).

The actual errors (from JavaDoc's POV) are below. These are probably bugs/limitations in genjavadoc.

[error] /home/travis/build/scala/scala-java8-compat/target/java/scala/compat/java8/StreamConverters.java:35: error: element not closed: code
[error]  * <code></code><code>
[error]        

[error] /home/travis/build/scala/scala-java8-compat/target/java/scala/compat/java8/StreamConverters$.java:35: error: element not closed: code
[error]  * <code></code><code>
[error]    

If memory serves, the workaround here is to use <code> block rather than {{{... }}}

And:

[error] /home/travis/build/scala/scala-java8-compat/target/java/scala/compat/java8/FunctionConvertersTest.java:17: error: class FunctionConvertersTest.Box is already defined in class FunctionConvertersTest
[error]   public  class Box implements scala.Serializable {
[error]           

We should disable the genjavadoc plugin for test sources. Another workaround would probably be to make Box a top level class.