Update build file to use springio-platform plugin
Fixes
Merge pull request #329 from rwinch/springio-platform-plugin

Fixes
Update to gradle 1.12
Implement a fork/join pool for doing arbitrary asynchronous task execution and coalescing the result into a Composable.
Fix compilation error on JDK <8
Updated Netty to 4.0.19. Added javadoc link reference to gs-collections API.
Update springio-platform-plugin version and repo reference.
Update the configuration of the Spring IO plugin

 - Update the version to 0.0.3.RELEASE
 - Apply the plugin to all projects
 - Add a dependency on the platform's versions

 With these changes ./gradlew clean springIoCheck -PJDK8_HOME=… builds
 cleanly
Merge pull request #332 from wilkinsona/update-io-plugin-configuration

Update the configuration of the Spring IO plugin
Make configuration of Spring IO plugin less invasive

The plugin is now only applied when the build is run with the
platformVersion property. This property is also used to determine
the version of the platform-versions dependency that will be used
by the springIoCheck task. This breaks a circular dependency between
the projects that are included in the Platform and the Platform
itself.
Tweak ForkJoinPool to handle joining tasks into a Promise differently than forking tasks using a Stream
Tweak how results are collected.
Add null check in case Registration becomes null.
Add ForkJoinPoolTests
Add a return after catching an interrupt
[artifactory-release] Next development version
Took out System.exit() from dispatch() and simply re-throw Exception after logging to stderr. Underlying error was possibly caused by some ints not being volatile (!) so fixed that which should prevent the catch in dispatch() from ever being triggered.
Merge pull request #333 from wilkinsona/io-plugin

Make configuration of Spring IO plugin less invasive
Fixes #294 by using Thread.getId() method instead of System..identityHashCode() to uniquely identify the JVM thread

According to #294, when using Java 7 the consumers of a workQueue or threadPoolExepcutor dispatcher based streams
receveied more calls than exepcted (some objects were dispatched to the consumer twice).
The reason was the AbstractMultiThreadDispatcher.allocateRecursiveTask() method where the System.identityHashCode(Thread.currentThread())
sometimes returned the same hash for different threads.
This fix replaces System.identityHashCode(Thread.currentThread()) with the Thread.getId() (available since JDK 1.5) to uniquely identify a JVM thread.