Builds two gems from one repo.

This update will now build two gems from within one repo.

### Building

Commands to build the gems:

* `rake build:core` under MRI or Rbx will build the pure-Ruby `concurrent-ruby` gem
* `rake build:core` under JRuby will be the Java-specific `concurrent-ruby` gem
* `rake build:ext` under MRI will build the `concurrent-ruby-ext` gem with uncompiled C extensions
* `rake build` under MRI will build the aforementioned `concurrent-ruby` and `concurrent-ruby-ext` gems
* `rake build` is an alias for `rake build:core` under JRuby or Rbx
* The [rake-compiler-dev-box](https://github.com/ruby-concurrency/rake-compiler-dev-box) scripts have not yet been updated

### Installing

The `concurrent-ruby-ext` gem lists `concurrent-ruby` as a runtime dependency. Installing `concurrent-ruby-ext` will cause `concurrent-ruby` to be installed.

Installing `concurrent-ruby` alone will install the JRuby-specific gem under JRuby. It will install the pure-Ruby gem under any other platform.

### Using

All the user ever needs to do is `require 'concurrent'` (or a load a subset of the gem, as in `require 'concurrent/atomic'` or `require 'concurrent/atomics'`) and the C extensions will load *if an only if* running under MRI *and* the `concurrent-ruby-ext` gem has been installed.

### Testing

1. Under MRI run `rake build` to create 2 gems
    * On any platform run `rake native gem` to build the pre-compiled extension gem
1. Under JRuby run `rake build` to create 1 gem
1. Under MRI install 2 (or 3) gems
    * `gem install pkg/concurrent-ruby-0.8.0.pre1.gem`
    * `gem install pkg/concurrent-ruby-ext-0.1.0.pre1.gem`
    * Optionally: `gem install pkg/concurrent-ruby-ext-0.1.0.pre1-x86_64-darwin-14.gem` (as appropriate for your platform)
1. Under JRuby install 1 gem
    * `gem install pkg/concurrent-ruby-0.8.0.pre1-java.gem`
1. Under Rbx install 1 gem
    * `gem install pkg/concurrent-ruby-0.8.0.pre1.gem`
1. Under MRI, JRuby, and Rbx run the following scripts and note the differences
    * `ruby examples/benchmark_atomic_boolean.rb`
    * `ruby examples/examples/benchmark_atomic_fixnum.rb`
    * `ruby -Ilib -Iext examples/bench_atomic.rb`

linking the versions makes sense and simplify working with it, look at what they do for rails (on this I like what they do ;) ).

Finding which ext gem is the match to a specific concurrent-ruby version might be a pain if the versioning is different, I already got bitten by this with another project and he can be a real pain to track back the right version when using older version of a gem.