(SERVER-38) Store JRuby scripting containers in pool queue

This commit stores JRuby `ScriptingContainer` objects created during
JRubyPuppet pool initialization into a hash along with their associated
`JRubyPuppet` object and puts the result into the pool queue in the
service context.  The consumers of pool instances were updated to borrow
the `JRubyPuppet` object from the new hash instead of just being able to
access the `JRubyPuppet` object directly.

In the previous commit, the `ScriptingContainer` objects were not stored
in the service context and would fall out of scope when the
`create-jruby-instance` function returned.  The container objects could
then be garbage collected later on.  During garbage collection, the
terminate logic on the container would clean up -- decrement the ref
count for -- any open `ChannelDescriptor`s.  If the ref count for the
`ChannelDescriptor` had been bumped up because a file had been opened
during a JRubyPuppet request and the associated container was
terminated while the file was still open, the call that the JRubyPuppet
request would make to close the file handle would result in JRuby
throwing a `BadFileDescriptor` exception -- an assert fired because an
attempt was being made to decrement the ref count on the descriptor
below 0.  By always holding a reference to the `ScriptingContainer`s,
the containers will not be garbage collected and, therefore, the race
condition around closing descriptors would be eliminated.
Merge pull request #227 from camlow325/bug/master/SERVER-38-keep-scripting-container-in-scope

(SERVER-38) Store JRuby scripting containers in pool queue