[Evolution-hackers] CamelService changes

[Matthew Barnes <mbarnes redhat com>]

To help smooth the way for the account-mgmt I've made a few improvements
to the CamelSession and CamelService APIs in 3.1.  It's not necessarily
the *final* APIs that will wind up in 3.2, but more like the first round
of changes leading up to 3.2.

* Every CamelService instance now has a unique ID string.  This will now
  be the primary way of identifying CamelServices, rather than comparing
  URL strings.

* Adding new services to the CamelSession and retrieving services from
  the CamelSession are now distinct operations, replacing the "create on
  demand" approach of the past.

  camel_session_add_service() is a new method that takes a UID string, a
  CamelURL, a CamelProviderType and a GError and tries to instantiate a
  new CamelService instance for the information given.

  camel_session_get_service() now simply takes a UID string, and is a
  straight-forward hash table look up.  It no longer references the
  returned CamelService, so you don't need to unreference it.

* CamelService now implements the GInitable interface, and can fail on
  instance creation.  This replaces its construct() method.

* The file storage location for CamelServices (really only CamelStores)
  has changed.  It is now simply:

      $(XDG_DATA_HOME)/evolution/mail/$(UID)

  rather than:

      $(XDG_DATA_HOME)/evolution/mail/$(PROVIDER_NAME)/$(URL)

  That means each CamelService has a permanent location for files that
  doesn't change if the user tweaks server settings or even changes the
  provider.

  CamelService will handle the migration itself during instance creation
  by reconstructing the old directory path, testing for existence, and
  if found, renaming the directory to the new form.

  This solves bug #546491 and also means we won't be leaving so much
  junk behind over time in the user's data directory.  It will also make
  it easier to clean up after ourselves when accounts are deleted.

* The UIDs given to CamelServices are taken from EAccounts.  But because
  an EAccount describes both a store and transport but has only one UID
  string, the CamelStore for the EAccount gets the UID string verbatim
  and the CamelTransport for the EAccount gets the UID + "-transport".
  It's a bit of a kludge for now, but will be cleaned up when the
  account-mgmt branch lands.

* For built-in CamelStores, the UID for the "On This Computer" store is
  "local", and the UID for the "Search Folders" store is "vfolder".  For
  now these are just hard-coded names.

The changes are behaving well for me so far, but I imagine I probably
broke a corner case or two in some provider somewhere.  Let me know if
you see anything amiss.