find builtin libraries on any classloader
added comment test case for ffi and osgi [skip ci]
* stay within the classpath: protocol

* unsure we pass on the Url with its URLStreamHandler provided by the classloader directly to the JRubyClassloader

remark on the URL:
currently there are plenty of issues where those embedded jars from jruby-stdlib
can not be loaded. AND if somehting goes wrong adding that URL to the JRubyClassloader
there will be no Exception so the actual error pops as some constant not found or
some import_java does not work. turning on debug.loadService often shows that jar could
be found and still it is not working. URL -> toString -> new URL( String ) is not reliable since
you always can construct URL objects with "custom" URLStreamHandler. the idea here to
just take whatever URL the classloader produces and pass it on the JRubyClassloader.
added the same readonly-fileStats to URLResource and ClasspathResource as JarResource has.
added directory listing info the jruby-stdlib.jar so ClasspathResource and URLResource
can use them to setup directory FileResource

with this the OSGiSCriptingConstainer and also the ScriptingContainer inside an OSGi bundle have
not default gems. most probably other J2EEContainer which do not "see" defaults gems with jruby-1.7.13
should see them now.

embedded gems will also work when they embedded directory supply a .jrubydir file with the directory listing.
integration test is not supplied here.

testing is currenly limited to high level integration tests
Merge branch 'jruby-1_7'

Conflicts:
	core/src/main/java/org/jruby/util/URLResource.java
remove strange error regarding picking the wrong ruby version in backports gem