load GnuPG libs needed by JNI via standard Android path

Now that the core libs are included in the standard Android way, we can
load the libs in the standard Android way. libgpg-error, libassuan, libgpgme,
and libpinentry are all needed by JNI stuff, so they are loaded in Java
space.  (libgcrypt and libkbsa are needed by things like gpg-agent, so they
don't need to be loaded into Java).

refs #1548
remove manual entry for libs/, its included automatically
implement POSIX setenv() to change app's env vars, which GnuPG requires

This allows GPG to set the env vars at app launch, and everything should
magically get the env. There are two things that require setting env vars:

* Android's linker can only find shared libs by looking in LD_LIBRARY_PATH,
  so in order for the GnuPG command line tools to find the required shared
  libraries, LD_LIBRARY_PATH needs to include the apps lib paths also.

* GnuPG needs env vars like GNUPGHOME to find the folder where keyrings,
  UNIX sockets, and config files are kept.

http://stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java

#1548
add Posix.setenv() for setting the global env vars of an app

Turns out that Android/Dalvik is much simpler than Java in this regard.  The
environment is quite directly linked into the dalvik process, while in Java,
changing the environment requires a bunch of reflection trickery because it
maintains the environment in a special way in the JVM process.

refs #1548
include full android env vars in environment.conf for pinentry

There was a backtrace coming from when pinentry-android tries to open the
PinEntryActivity with /system/bin/am, this made that go away.

refs #2744

backtrace:

pinentry-android.c  D  sending intent with: exec /system/bin/am start -n info.guardianproject.gpg/info.guardianproject.gpg.pinentry.PinEntryActivity --activity-no-history --activity-clear-top --ei uid 10043 --user 0
pinentry-android.c  D  start_server /data/data/info.guardianproject.gpg/app_home/S.pinentry
    AndroidRuntime  D  >>>>>> AndroidRuntime START com.android.internal.os.RuntimeInit <<<<<<
    AndroidRuntime  D  CheckJNI is OFF
          dalvikvm  D  Trying to load lib libjavacore.so 0x0
          dalvikvm  D  Added shared lib libjavacore.so 0x0
          dalvikvm  D  Trying to load lib libnativehelper.so 0x0
          dalvikvm  D  Added shared lib libnativehelper.so 0x0
       Environment  W  EXTERNAL_STORAGE undefined; falling back to default
          dalvikvm  W  Exception Ljava/lang/NullPointerException; thrown while initializing Landroid/os/Debug;
          dalvikvm  I  Exception thrown by dispatcher for 0x48454c4f
          dalvikvm  I  java.lang.ExceptionInInitializerError:
          dalvikvm  I  at android.ddm.DdmHandleHello.handleHELO(DdmHandleHello.java:140)
          dalvikvm  I  at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java:86)
          dalvikvm  I  at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
          dalvikvm  I  at dalvik.system.NativeStart.run(Native Method)
          dalvikvm  I  Caused by:
          dalvikvm  I  java.lang.NullPointerException:
          dalvikvm  I  at java.io.File.fixSlashes(File.java:185)
          dalvikvm  I  at java.io.File.<init>(File.java:134)
          dalvikvm  I  at android.os.Environment.getLegacyExternalStorageDirectory(Environment.java:322)
          dalvikvm  I  at android.os.Debug.<clinit>(Debug.java:97)
          dalvikvm  I  at android.ddm.DdmHandleHello.handleHELO(DdmHandleHello.java:140)
          dalvikvm  I  at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java:86)
          dalvikvm  I  at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
          dalvikvm  I  at dalvik.system.NativeStart.run(Native Method)
          dalvikvm  I  Rejecting re-init on previously-failed class Landroid/os/Debug; v=0x0
          dalvikvm  I  Exception thrown by dispatcher for 0x46454154
          dalvikvm  I  java.lang.NoClassDefFoundError: android/os/Debug
          dalvikvm  I  at android.ddm.DdmHandleHello.handleFEAT(DdmHandleHello.java:152)
          dalvikvm  I  at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java:88)
          dalvikvm  I  at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
          dalvikvm  I  at dalvik.system.NativeStart.run(Native Method)
          dalvikvm  I  Rejecting re-init on previously-failed class Landroid/os/Debug; v=0x0
          dalvikvm  I  Exception thrown by dispatcher for 0x4d505251
          dalvikvm  I  java.lang.NoClassDefFoundError: android/os/Debug
          dalvikvm  I  at android.ddm.DdmHandleProfiling.handleMPRQ(DdmHandleProfiling.java:181)
          dalvikvm  I  at android.ddm.DdmHandleProfiling.handleChunk(DdmHandleProfiling.java:84)
          dalvikvm  I  at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java:171)
          dalvikvm  I  at dalvik.system.NativeStart.run(Native Method)
hide comment field and make it optional when creating keys

The Comment: field is little understood and usually misused.  So hide it
and give a checkbox to enable it for people who actually want to use it.

http://debian-administration.org/users/dkg/weblog/97

closes #1960
Eclipse ADT insists on marking some things as exported in .classpath

Who knows what this does anyway?
REMOVE ME enable debug logs
update pinentry submodule to include updated parsing of environment.conf

refs #1548
remove redundant return statement in android_cmd_handler

refs #2744, #1275
lots of debug messages for pinentry
implement changePassphrase() and purge old non-functional passphrase code

gnupg-for-java was written for GnuPG 1.x with GPGME.  The expectation there
was that the passphrase prompt was handled by the client app.  Now in GnuPG
2.x, all passphrase prompting is handled by GnuPG pinentry, which is always
triggered by gpg-agent.

This commit hooks up the current function to trigger the passphrase change,
and removes the old dead code for GnuPG 1.x

closes #1585
make project build depends work better so builds don't always get triggered

Currently, it seems that the dependencies, i.e. libgpg-error, get build
everytime no matter what.  This puts the depends on the installed .so file
so that should make it a bit more reliable.  Changing the installed .so
file will trigger a rebuild of that project and the dependent projects.
Not great, but better than before...

refs #1548