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.