buildArgs must be on the Java side
Branch b1: step I

The REXX activity gets single-top
Branch b1: step II

Clean up the mess. Make rexxlib / toolslib independent of Android.
Init and finalize Rexx context, n times interpreting in the meanwhile.

Following the "activity-single-top" change, `init' and `finalize' were required
to be able to shell Rexx from an already alive Rexx, while keeping
same SystemContext: JConsole, Speaker, files, etc.

Each "interpret" runs on its own thread, and I realized that the JNIEnv pointer
was being modified while switching threads, as well as the JVM reorganizing the
addresses of the objects (after a Garbage Collection.)

For the former, I created a global field g_jniEnv, set at each `interpret' call,
reset at the end.  I'm not relying anymore in a same env pointer being part of
any instances that need it: they will use the volatile g_jniEnv field.

For the latter, I had to pin down the instances (Speaker, JConsole) to make
the JVM consider them as "unmoveable" addresses, that is using NewGlobalRef
the address of which is deemed to stay constant among threads.
Ensure all is cleaned-up when returning from Rexx activity
Shut your big mouth, AM!
Looper quit must be b4 stopping TTS
Cleaned-up.  Almost done on branch b1
Not too sure on how useful those changes are...

I'm still chasing the erratic SIGSEGV sometimes occurring when pressing
the back button. I was thinking the Speech class was the culprit; I revamped
the Speech termination, and, IMHO these changes are rather better, or
at least harmless. But this is not it.

It looks like ScriptsList that starts Rexx may be destroyed
before Rexx is destroyed. This dangling order might be at the
origin of the problem, and I will try to fix it in next commit.
Fix for a couple of real bugs:
- the Speaker nullified erroneoulsy the ServiceConnection before it was ended
- Rexx was throwing an exception, badly killing the activity

Also, I cleaned the Exploder.
Defense against a null speaker
Fix for problems in REXX Activity lifecycle.

Finally!  This code seems to have robust manners to keep a sane SystemContext
among the several ways Rexx can be called. The solution was to use the
couple onStart/onStop rather than onCreate/onDestroy.

It might look obvious, but it wasn't. I spent 2 days before to arrive to
this solution.  I tried a Ref'ed SystemContext, and to make Rexx single task
(but this doesn't work, because Google decided to secure access to GMail
attachments, for onNewIntend.)  I even wrote a LocalBroadcaster! Nothing
worked, a pain in the neck at fighting SIGSEGV's all over the place.

Rereading carefully the Activities'lifecycle -- despite Google efforts for
documenting, this part is still unclear for many -- I found out that the
onStart/onStop had to recreate the SystemContext, b/c I could not keep
the same context for Rexx started from the App, and Rexx started as an intent
for executing mail attachment, or file association.

REXX'SystemContext is really what it says it is: independent of REXX'guts
(that is: clauses, the stack, etc..), it's just a kind of Helper to redirect
the output/input (serambuffers) resources to what's appropriate in a given
(new) context.
Speaker language optimized

At profiling REXX, I found that the 3sec lag observed at the start of an
interpretation (associated file or attachment) was only due to the system
setting the language.

"Speech" has been modified so that a language change only occurs when it
is required.
Added Rexxoid's crown for logo
Final on branch b1