FJ: initial sketch implementation.

This is the general idea of what I'm thinking of for fork-join. We have a method `Concurrent#join` which takes a block. In that block you have calls to `fork`, to which you pass blocks for your concurrent tasks.

    values = Concurrent::join do
      fork do
        ...first concurrent task...
      end

      fork do
        ...second concurrent task...
      end
    end

For us this can be implemented as a simple layer over futures. If we're happy with how this looks I will tap into the work-stealing scheduler that backs Java's fork-join for an efficient implementation.

People would use this fork-join syntax over futures and dataflow because it's a simpler model. The program is sequential before and after the call to `Concurrent#join`, and there are no asynchronous values or parallel objects to deal with, just a well defined block of tasks that execute concurrently. You can see exactly what's running concurrently, because they're neat little blocks lined up against each other.

This makes it particularly well suited to adding to an existing program or library, especially where the rest of the program is expecting a synchronous result and you can't build a larger dataflow graph. You can easily make a single part of the program concurrent.

Thoughts?