Global thread pool is now a thread pool executor.

@mighe @chrisseaton @lucasallan 

In this PR I've made the global thread pool a `ThreadPoolExecutor` instance. Before this commit it wasn't a real thread pool. It was a `PerThreadExecutor` (formerly `NullThreadPool`) which spawned a new thread for every request. I'd like to discuss if this is the best direction for this gem. There are two issues to discuss:

1. Is this a reasonable configuration? The links below are some sites I found while randomly searching Google for "global thread pool configuration". They provided some guidance.
2. The Java thread pool doesn't seem to shut down on exit. During experimentation I've had to explicitly shutdown the pool otherwise the program just hangs and I need to `kill` it. Is there a way to prevent this? If not, we may have to default to a Ruby thread pool even when running under JRuby.

I've added a demo program at `demos/global_thread_pool-demo.rb` that creates 500 `Future` objects each of which makes a call to a RESTful API. It outputs the time it takes to perform the task both sequentially and concurrently.

* http://otndnld.oracle.co.jp/document/products/as10g/101300/B25221_03/web.1013/b14432/threadpool.htm#BHBBGCFA
* http://docs.jboss.org/hornetq/2.3.0.CR2/docs/user-manual/html/thread-pooling.html#server.scheduled.thread.pool
* http://msdn.microsoft.com/en-us/library/dd997402(v=vs.110).aspx
* https://tomcat.apache.org/tomcat-7.0-doc/config/executor.html
* http://www.percona.com/doc/percona-server/5.5/performance/threadpool.html
* http://documentation.progress.com/output/Iona/artix/2.0/prog_guide/artix_dev18.html