Support loading from UnoJars, and prefer dependencies in the supplied unojar

[nsoft]

This is essentially a port of a class used in JesterJ to make it more widely available. The basic idea is to alter the classloader delegation scheme. By default classloaders always check the parent first. However an uno-jar is meant to provide a full set of dependencies and so if we encounter an unojar inside /lib we should exhaust all the libraries supplied by that unojar before searching our parent classloaders.

The result will be a get out of jail card for Jar Hell that involves building an uno-jar for at least one of the conflicting libraries. This is useful in JesterJ because it allows User defined code loaded at runtime to opt out of the vast number of dependencies that JesterJ currently relies on.

More generally this capability will allow for modularization of sub-components and eliminate the need to synchronize dependencies across builds and sub-builds. That will of course come with the cost of bloating the fat jar even further.

If this is successful a follow-on feature may seek to enable a recursive exploration of the included libs and uno-jar libs to "pull up" any duplicate dependencies when possible.

[nsoft]

Some thinking about this has led to the realization it's going to get slightly tricky when multiple UnoJars are included inside the main unojar The following case must be handled:

TopUno.jar
|
+--/main/main.jar
+--/lib
   +--Log4j2-2.13.0.jar
   +--foo.jar
   +--FirstSubUno.jar
   |  +--/main/main.jar
   |  +--/lib
   |     +--bar.jar
   |     +--Log4j2-2.14.0.jar
   +--SecondSubUno.jar
   |  +--/main/main.jar
   |  +--/lib
   |     +--baz.jar
   |     +--Log4j2-2.15.0.jar
   |     +--SubSecondSubUno.jar
   |         +--/main/main.jar
   |         +--/lib
   |            +bam.jar
   +--ThirdSubUno.jar
      +--/lib
          +--bat.jar
          +--SubThirdSubUno.jar
             +--/main/main.jar
             +--/lib
                +bag.jar

1. Classes in the main.jar should use 2.13
2. Classes in foo.jar should use 2.13
3. Classes in FirstSubUno.jar's main.jar and bar.jar should use 2.14 (and never 2.15, regardless of order)
4. Classes in SecondSubUno.jar's main.jar and baz.jar should use 2.15 (and never 2.14, regardless of order)
5. Classes in SubSecondSubUno.jar's main.jar and bam.jar should use 2.15
6. Classes in ThirdSubUno.jar's main.jar and SubThirdSubUno.jar's main.jar bat.jar and bag.jar should use 2.13

It's unclear as yet how to achieve that because the JVM lazy loads dependencies, so we may have trouble understanding what class is causing the load (and therefore what the associated codesource should be).

[nsoft]

After thinking about it a bit I believe that the above pattern is actually not that hard to achieve, the key thing to remember is it's a bottom up process, and the only case where you can possibly "see sideways" is when you don't find the class locally. So the problem case is case 6 above, because JarClassLoaders check their EXT loader first (and the current thought would be to have a list of ext loaders, but maybe the list needs to be a separate concept?)

[nsoft]

Another key challenge here is there is some work done by Boot.java that will need to be done for child uno-jars such as reading the binlib resolver from the manifest of the unojar...

[nsoft]

Above changes were pushed to 1x and 1.1 because the change should be more correct overall and is unlikely to make a difference for any cases other than this issue.