Experimental CAtomicFixnum -- DO NOT MERGE

@chrisseaton @mighe 

I did some more experimentation with `CAtomicFixnum`. First, I created a benchmark test that spawned multiple threads. In retrospect it didn't make much sense to test a concurrent object on only one thread. I also took Chris' suggestion and experimented with GCC's atomic operations. Which lead to the discovery that Travis CI doesn't have a new enough gcc. So I updated the code support both. I then ran a benchmark test that spawned ten threads and ran several million operations against an `AtomicFixnum`. I used both MRI 2.1.1 and JRuby 1.7.11. My computer has two cores. The MRI implementations were significantly faster. One thing to note: `CAtomicFixnum` operates entirely within the GIL.

```ruby
# About This Mac
# Processor 2.93 GHz Intel Core 2 Duo
# Memory 8 GB 1067 MHz DDR3

# ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-darwin13.0]
#
# Testing with Concurrent::MutexAtomicFixnum...
#=> 21.180000  55.370000  76.550000 ( 54.700031)
#
# Testing with Concurrent::CAtomicFixnum...
# with GCC atomic operations
#=> 1.270000   0.000000   1.270000 (  1.273004)
#
# Testing with Concurrent::CAtomicFixnum...
# with pthread mutex
#=> 1.980000   0.000000   1.980000 (  1.984493)

# jruby 1.7.11 (1.9.3p392) 2014-02-24 86339bb on Java HotSpot(TM) 64-Bit Server VM 1.6.0_65-b14-462-11M4609 [darwin-x86_64]
#
# Testing with Concurrent::MutexAtomicFixnum...
#=> 12.060000   5.760000  17.820000 ( 11.731000)
#
# Testing with Concurrent::JavaAtomicFixnum...
#=> 3.940000   0.070000   4.010000 (  2.118000)
```