Fix coercion of arrays in Kernel#Array and Array#product.

Fixes #1961.
Fixes #1962.
Specs for #1961 and #1962.
Fix bug numbers.
This is not correct for 1.8, so mask it.
Port MRI logic for "check funcall" used by type conversion.
Mask the other spec...also 1.9-specific.
Fixes #1700. NPE in Ripper with $ special variables
load resources from jruby-classloader
each required jar will be added to the LOAD_PATH removing the need to handle
those jar (and its ruby script content) explicitly with the JRubyClassloaderResource
putting the jruby-classloader as context classloader means that all attached "jars" can be found via
the Thread.currentThread.contextClassLoader which means all ruby scripts will be found through this pass.
running jruby from other environments like servlets just leave the context classloader as parent.

Dir-glob does not work in general with the Thread.currentThread.contextClassLoader and this would also
shadow the LoadPath entries for the attached jars since the context-classloader gets inspect first

finally it keeps the classloader semantic uniform wether executed from commandline or inside a j2ee container
or osgi framework
each required jar will be add to LOAD_PATH using jar:file: protocol URIs. with
this all Dir glob, etc will work on those jars and its embedded ruby scripts.
ignore file: protocol if present
call generated script differently then the any existing files, to avoid finding
it on the classpath and loadpath
run the load_path test only in 1.9 mode since 1.8 finds things on CWD
adjust Dir.entries to be uri-like
add "." to LOAD_PATH as some test need this
in some environments JRuby is not loaded via the context-classloader
use runtime.getCurrentDirectory to determine whether a ruby script comes from "."
just add "!" to jar entries of LOAD_PATH
do not test for working openssl on OSGIScriptingContainer