Changes

added android x86 support.

Support architecture ppc64le (Debian ppc64el).

Bug 682: Rename com.sun.gluegen -> com.jogamp.gluegen in doc/**

Use system property to detect Android

Adding 'jogamp.gluegen.TestTempDirExec' property, allowing to disable
testing executable of temp dir
This also avoids trying to unpack the test executable on Windows, which
may cause a virus scanner to halt the process or otherwise cause issues.

local build windows scripts: add 7zip to path

Eclipse: Move android.jar to classpath end, avoid junit override

Bug 1219, Bug 1231: Avoid deflating test-exe on Windows using
java.nio.file.Files.isExecutable(Path)
Attempt to resolved virus scanner false positive detection on Windows 
while deflating the native code test-exe file in the temporary folder.
As Julien Gouesse suggested, using Java 1.7's
java.nio.file.Files.isExecutable(Path)
_may_ resolve the issue, this has to be thorougly tested.
This patch favors the nio's isExecutable file's ACL test over the more
intrusive execution itself using a simple shell script file w/ set
executable flag.
Mind that previous tests allowed the shell script's execution, even if
the temp folder did not allow execution of native code.
We have to see how our testing results will be on this attempt.

Bug 1219, Bug 1231: Re-add executable test by execution
Re-adding executable test by execution is required for 'blocker
technology' like Windows's 'Software Restriction Policies (SRP)', which
only gets activated by the actual execution attempt. Merely testing the
file's (ACL) execution flags via NIO's isExecutable is not sufficient.
Implementation first tests the file's (ACL) execution flags via NIO's
isExecutable. If the NIO test was successful or not available, the
actual execution test is performed.
To mitigate the virus scanner's false positive, we use an executable
shell script per default now, which may be overriden by the new
environment 'jogamp.gluegen.UseNativeExeFile=true'
Tested on GNU/Linux with one temp folder having mount options 'noexec' 
and on Windows using Software Restriction Policies (SRP) disallowing one
temp folder. Both temp folder were first in line via environment
'java.io.tmpdir'.

Update HowToBuild.html
Minimum supported Debian version is now Debian 9 or Stretch to minimize
maintenance. Note: No other GNU/Linux version has been validated so far.

Bug 1316: MacOSX: Keep *.dylib (Don't move to *.jnilib)
Since Java8 (or even earlier), JRE on OSX uses *.dylib native library
suffix instead of *.jnilib when automatically searching and loading
them.
This is not easily being recognized by JogAmp, since we explicitly name 
the native libraries with full path when testing with our TempJarCache.

Bug 1366 - Use String.format((Locale)null, "..." ..) avoiding Locale
output for System related Operations

Bug 1367: Make TempFileCache & TempJarCache even if temp folder can't
handle executables

Bug 1369: Source Certification Contract (SCC): Initial SHA256
fingerprint & runtime validation
This change implements a strong SHA256 signature over: 1) source tree
inclusive make recipe (SHA256-Source) 2) all class files
(SHA256-Classes) 3) all native libraries (SHA256-Natives) 4) the class
files as deployed in the jar (SHA256-Classes-this) 5) the native
libraries as deployed in the jar (SHA256-Natives-this)
and drops all of these in the deployed Jar file.
This allows SHA256 validation of (4) + (5) at runtime and further
complete validation (1), (2) and (3) offline.
Full SCC would now required (1) - (3) to be placed on a server for
further validation. Optionally we may use GPG <https://gnupg.org/> or
PGP to validate the build entity to implement the chain of trust
<https://en.wikipedia.org/wiki/Chain_of_trust>
The SHA256 runtime validation is tested via:
com.jogamp.common.util.TestVersionInfo

OpenJDK8 Script Usage: Linux: Favor Debian default; Windows: Use
AdoptOpenJDK8

Bug 1367: TempJarCache: Fix Unit Test using Reflections

Bug 1369: SCC: Hide SHA Algorithm bit size in literals of Specification
Implementation currently uses 256 bit Secure Hash (SHA) algorithm, but
this may change in the future. Hence only use 'SHA' in the names, not
'SHA256'.

Bug 1369: SCC: Clarify & fix build dependencies in build.xml
Clean 'base.compile' order w/ matching build -> package tuples, having
gluegen.build.shasum after the last actual build and before packaging.
- init,
- android-launcher.build,
- gluegen.build.java,
- gluegen.build.native,
- gluegen.build.shasum,
- gluegen.package.java,
- gluegen.package.native,
- android-launcher.package
Further properly utilize a 'gluegen.package.*.done' property, 
corresponding with the 'gluegen.build.skip.*' property.
Drop 'build.javaonly' gluegen.build.native exclusion