Fix "argLine" parameter in core/pom.xml

Maven does not accept more than one tag
Merge pull request #1885 from gustavotemple/fix-argline-pom

Fix "argLine" parameter in core/pom.xml
allow uri: protocol - uri: are all absolute
treat all none jar: uri internally as uri: protocol
treat uri: the same way as classpath: pseudo protocol
introduce uri: protocol which allows to use uri from any classloader and use
them for LOAD_PATH and GEM_PATH.

$LOAD_PATH << myClassloader.getResource( "/" )
Gem::Specification.dirs << myClassloader.getResource( "/" )

of course you can add another classloader

$LOAD_PATH << anotherClassloader.getResource( "/" )

if also introduce a ".jrubydir" which the URLResource tries to find in order
to produce directory info for the loaded file.

some classloaders do not return an uri with getResource( "/" ) this .jrubydir
can help to find the classloader root-uri

the file format for .jrubydir is the same as "$ ls -1" one directory entry per line
to allow the ScriptingContainer to JRubyHome it can NOT be treated as NormalizedFile since // has to remain as // in a uri:-file
follow the changes of URLResource without introducing .jrubydir
produce .jrubydir for jruby-stdlib
treat all uri: files with URLResource and set exists accordingly whether the uri is valid and/or can be read
added tests for expand_path and fixes to pass them
added unit tests for directory listing of uri: files
get the OSGi IT in place with embedded gems, default gems, relative_require, etc
this test case has one OSGi bundle with embedded gems, one bundle with ruby scripts
and the third bundle embeds JRuby itself and runs some tests using the scripts and the gems
fix NPE
make sure Pathname works when finding uri: files
delete obsolete files
added helper methods to JRuby::Commands to generate directory info files for embedded setup
introduce uri:classloader: pseudo protocol which uses Thread.currentThread.contextClassLoader
to find the resource. the uri pattern does not work with jboss-wildfly when a war gets deployed unexploded.
the IsolatedScriptingContainer detects the whether it is used with
a Thread.currentThread.contextClassLoader (J2EE) or with the classloader
which loaded IsolatedScriptingContainer.class (OSGi case)

the setup of LOAD_PATH and GEM_PATH and JRUBY_HOME uses ONLY uri: or uri:classloader:
protocol paths. i.e. everything lives within one or more classloaders - no jars added from
jave.class.path or similar "magics"

the root of the "main" classloader is add to LOAD_PATH and GEM_PATH.

in the OSGi case there are helper methods to add ClassLoaders to the LOAD_PATH or GEM_PATH