NaCl cleanup: Stop connecting to the SRPC trusted command channel

NaCl cleanup: Stop connecting to the SRPC trusted command channel

Before this change, the SetupCommand() call in service_runtime.cc
connected to the SRPC trusted command channel.  We replace this with a
subset of what SetupCommand() did.  (Note that the renderer can still
connect to the *untrusted* SRPC command channel, which is used by the
PNaCl translator.)

Before, we were not sending any messages on the trusted command
channel, but the NaCl loader process was detecting EOF on the channel
and exiting in response (via a call to NaClAppShutdown() in
nacl_secure_service.c).  We replace this with new logic in
nacl_trusted_listener.cc which detects EOF on a Chrome IPC channel.

 * This happens to be tested indirectly via tests for the GDB debug
   stub.  They hang if the NaCl loader process sticks around after an
   <embed> element is deleted.

 * This change changes the debug stub's behaviour slightly: If a NaCl
   process is forcibly terminated (such as by its <embed> being
   deleted), GDB will get an EOF on the debug socket without seeing a
   SIGKILL (-9) exit status being reported first.  I'm not sure it's
   worthwhile doing the extra plumbing to keep the original "-9"
   status reporting (which was added for https://crbug.com/157881).

   Before, GDB prints:
     Program terminated with signal SIGKILL, Killed.
     The program no longer exists.

   After, GDB prints:
     Remote connection closed

 * Remove the existing OnChannelError() because it never gets called.
   A call to it get queued on the main thread, but the main thread
   gets blocked in NaClChromeMainAppStart().

BUG=496287
TEST=debug stub tests: NaClGdbDebugStubTest.*, NaClBrowserTestPnaclDebug.*

Review URL: https://codereview.chromium.org/1153293003

Cr-Commit-Position: refs/heads/master@{#334097}