README: Add new IRC channel, mark Jabber deprecated
Android Completion for launching main() class via MainLauncher; Fix ActivityLauncher order of delegation/super activity callbacks.

- StaticContext:
  - Add ViewGroup for standalone tests w/ UI

- MainLauncher/LauncherUtil:
  - Complete launching a main() class from our activity launcher
  - adding main-cmdline-args

- ActivityLauncher
  - Fix order of delegation/super activity callbacks.
Buffers: Fix typo
RecursiveLock.getHoldCount(): Fix API doc formatting
test script
PlatformPropsImpl: JAVA_RUNTIME_NAME is null using GCJ gij JRE.

Signed-off-by: Xerxes Rånby <xerxes@zafena.se>
Buffer.isDirect() operation is undefined w/ Eclipse ecj and GCJ gij JRE.

Fix for the runtime error using GCJ gij JRE:
java.lang.NoSuchMethodError: method java.nio.Buffer.isDirect with signature ()Z was not found.
at com.jogamp.common.nio.Buffers.isDirect(Buffers.java:363)

Also Eclipse ecj refuses to compile code using java.nio.Buffer.isDirect().
----------
1. ERROR
...
        return ((Buffer) buf).isDirect();
	                      ^^^^^^^^
The method isDirect() is undefined for the type Buffer

Signed-off-by: Xerxes Rånby <xerxes@zafena.se>
Merge remote-tracking branch 'xranby/gcj-gij'
Modified Java 1.5 Buffers patch 2b7d1b1d25cb2cd73311ec9159b465f0391bf5e0 - May break GCJ/ECJ .. needs to be revised.

- Adding JAVA_6 in PlatformPropsImpl
- Buffers.isDirect() chooses fast-path iff JAVA_6, otherwise using reflection (GCJ/ECJ)
- Adding JAVA_6 info in VersionUtil
- API doc: Refine JAVA_SE and JAVA_6 spec.

TODO: In case GCJ etc is unable to compile the JAVA_6 code
      even though it uses a static condition (probably not),
      We have to wrap isStatic in an own class, one for JAVA_6 and one for <= 1.5.
      This will be a good exercise for further issues we may have w/ Java <= 1.5.
Add MainLauncher adb launch script. Here we only utilize non-root features, i.e. can be launched on non-hacked device.
MainLauncher: Remove Thread.destroy() - n/a on Android ..
Fix ActivityLauncher/MainLauncher .. and make adb-launch-main more suitable

- ActivityLauncher
  - no finish() from onDestroy()

- MainLauncher
  - finish activity after returning 'main()' returns
  - no finish() from onDestroy()

- adb-launch-main:
  - Clear logcat
  - Wait until activity is stopped
  - Dump logcat to local logfile
adb-launch-main: logcat: append to log
GlueGen: NativeLibrary Fix, JNILibLoaderBase Enhancement

- NativeLibrary Fix
  - enumerateLibraryPaths(..):
     - Properly iterate through all prefix _and_ suffix.
     - Make public for JNILibLoaderBase.loadLibraryInternal(..)

  - isValidNativeLibraryName(..):
     - Stop iterating through prefix, if previously found
       but suffix doesn't match.

- JNILibLoaderBase.loadLibraryInternal(..) Enhancement
  - Mark customLibLoader FIXME: remove (we will get rid of jnlp.launcher.class)

  - If System.load(TempJarCache) and System.loadLibrary(plainLibName) fails,
    use NativeLibrary.enumerateLibraryPaths() w/ System.load(..) as last resort.

Tested on Linux x86_64 Java6 and OSX Java7 manually, no regressions expected.
Add OSX Java7 build script
Bump Android NDK to 'android-ndk-r8d' - Note: '-fno-use-linker-plugin' is required (?!)
Cleanup GlueGen config 'ExtendedInterfaceSymbols*'

Semantics Change:
  ExtendedInterfaceSymbolsOnly was used for implementation generation only,
  which is considered a bug!

- ExtendedInterfaceSymbolsIgnore C.java
  - Ignore symbols in C.java for interface generation
- ExtendedInterfaceSymbolsOnly C.java
  - Only use symbols in C.java for interface generation
- ExtendedImplementationSymbolsIgnore C.java
  - Ignore symbols in C.java for implementation generation
- ExtendedImplementationSymbolsOnly C.java
  - Only use symbols in C.java for implementation generation
- ExtendedIntfAndImplSymbolsIgnore C.java
  - Ignore symbols in C.java for interface and implementation generation
- ExtendedIntfAndImplSymbolsOnly C.java
  - Only use symbols in C.java for interface and implementation generation
Fix comments in gluegen-cpptasks-android* config file
Android: Cleanup ClassLoaderUtil/LauncherUtil - Using cached parent ClassLoader for SYS-Packages w/ native libs, and non cached child ClassLoader for USR-Packages

Android's Dalvik VM, like a JVM, cannot load a native library from one location by multiple ClassLoader.

Since we don't like to hardcode the system-packages, as it was before, i.e. "com.jogamp.common", "javax.media.opengl",
we need to either copy the libs or use parenting of cached ClassLoader.
The latter is chosen, since it's faster and uses less resources.

- System-packages are passed through from the user 'List<String> LauncherUtil.BaseActivityLauncher::getSysPackages()'
  to the ActivityLauncher, which instantiates the ClassLoader.

- No more hard-reference the system-packages in ClassLoaderUtil ("com.jogamp.common", "javax.media.opengl"),
  just use the new user provided system-packages.

- The system-packages denominate a hash-key for caching, a new ClassLoader is created and mapped
  if it does not yet exist.

- A non-chached user-packages ClassLoader is created using the cached system-packages ClassLoader as it's parent.
IOUtil.copyStream2ByteBuffer: read while numRead > -1 ; add variant w/ initialCapcity