[sugar] A few small fixes for the GUI's PresenceService client

[Mike C. Fletcher]

I've been trying to avoid modifications to code as we are focusing on 
the documentation, but as I couldn't load or test Sugar due to whatever 
it is that's broken on my install, I felt I needed to fix a few problems 
this evening.  With the checked-in changes I can run a Sugar checkout in 
my emulated environment again (though without the PresenceService and 
with all theme-based icons missing).

To answer any "whys?":

    As a general rule, we should *not* be letting the Shell die/fail to
    start just because it can't find a certain service.  The effect for
    the user is to wind up staring at a blank Xephyr screen, with no
    feedback on what went wrong and no way forward to try to solve the
    problem other than a quick crash-course on how to manage and
    configure a Unix machine from the command prompt.

    Machines will get:

        * borked configurations
        * corrupted files
        * messed up library versions
        * conflicting service files
        * disks or memory so full the system can't create a service
        * aborted upgrade procedures
        * <you name it here>

    and we need the shell to be written to handle those situations as
    much as possible.  The same changes also make it easier to develop
    for the platform because the system can "go" even if some dependency
    is malfunctioning at the moment.

Changes:

    * fix sugar.presence.presenceservice.PresenceService to deal with
      failures to connect with the PresenceService (which is the
      proximate error that has been preventing me from loading Sugar on
      my emulator)
          o uses a property object for the _ps member, catches dbus
            exceptions on failure, caches on success
          o adds an _OfflineInterface that provides a null
            PresenceService API
          o alters the unprotected interfaces on the class to watch for
            dbus exceptions
    * minor restructuring of sugar-emulator script
          o avoid executing setup code at the top level of the script
                + allows auto-documentation systems to process the
                  module without side effects
                + eventually allows for using automatic .egg "script"
                  entry-points using the script as a module, should we
                  decide to use .eggs for distribution at some point.
          o adds console log messages  telling the developer what's
            being done so they can tell what's failing

One weird thing seems to be happening; the logging module doesn't seem 
to be handling %s formatting for the logs I'm writing in presence 
service.  I guess something's been wrapped around the standard logging 
operations that's causing that.

Have fun all,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com